November 2020 - webkit-dev - lists.webkit.org

2020 WebKit Contributors Meeting - Save the Date
by Jonathan Davis 10 Nov '20

10 Nov '20

Hello WebKit Contributors, You are invited to participate in a virtual WebKit Contributors Meeting hosted online via WebEx on Monday, November 16th from 8 AM to around noon Pacific and Tuesday, November 17th from 1 PM to around 6 PM Pacific. To attend you must be an active contributor to the WebKit open-source project. The meeting will be free of charge, and registration will open soon. The event will feature presentation-led discussions of 10-40 minutes long, followed by queue-moderated discussion. If you have a topic to present for discussion, please email me, or message me on WebKit Slack. Feel free to reach out to me with ideas or questions on this year’s online event. Thank you, Jon Davis

1 1

Request for position on changing click, auxclick, contextmenu to PointerEvent
by Liviu Tinta 06 Nov '20

06 Nov '20

Hello WebKit-dev, I'd like to ask for Webkit's official position on changing “click”, “contextmenu”, “auxclick” events to PointerEvent (instead of MouseEvent) to let developers: - distinguish between mouse, pen and individual fingers in a multitouch interaction through pointerType and pointerId attributes, and - utilize fractional event coordinates for high precision use cases There were concerns about compat implications of this change but our compat study (see below) does not support those concerns. The "click" and "contextmenu" events were defined as MouseEvents decades ago when a mouse was the only source of pointer-like events. The "auxclick" event was defined similarly only a few years ago. The ability to distinguish these events by input source in a multi-pointer environment is a long-standing developer request (e.g. this MSDN request [1]). PointerEvents spec discussion [2] reached consensus that it would be a useful change and also expressed compat concerns [3]. Compat Study To better understand compat implications, Chrome committed [4] to experimenting in the wild. Chrome made the change available as an experimental web-platform feature in Sep 2019, started an experiment in Canary in Aug 2020, and gradually expanded the scope of the experiment to cover Canary, Dev and Beta by Nov 3rd 2020. So far there were no related bug reports. Related specification changes: - PointerEvents pending PR [5] - UIEvents merged PR [6] - Html pending PR1 [7] - Html pending PR2 [8] Mozilla standards-position: https://github.com/mozilla/standards-positions/issues/455 TAG Review: <https://github.com/w3ctag/design-reviews/issues/537>The TAG review process is being skipped because this change does not involve a design decision. [1] https://social.msdn.microsoft.com/Forums/en-US/d50efbfd-fb96-47d8-86e3-98c0… [2] https://github.com/w3c/pointerevents/issues/100 [3] https://github.com/w3c/pointerevents/issues/100#issuecomment-304941643 [4] https://lists.w3.org/Archives/Public/public-pointer-events/2019AprJun/0071.… [5] https://github.com/w3c/pointerevents/pull/317 [6] https://github.com/w3c/uievents/pull/259 [7] https://github.com/whatwg/html/pull/5324 [8] https://github.com/whatwg/html/pull/6126 Thank you, Liviu Tinta

1 0

Build bot workers aperez-{wpe, gtk}-ews to be rebooted for maintenance
by Adrian Perez de Castro 06 Nov '20

06 Nov '20

Hi all, Quick PSA: the two build bot workers I run will be brought down for a short period of time at 05:30 PST due to a kernel update; the machine where they are hosted is going to be rebooted. Most likely this will take only a few minutes =) Cheers, —Adrián

1 1

Container Queries
by Anders Hartvoll Ruud 05 Nov '20

05 Nov '20

Hi, We're about to start looking at Container Queries <https://github.com/dbaron/container-queries-implementability#proposal> in Chromium. The syntax is a bit up in the air at the moment, so ignoring that, I was wondering what Webkit's feelings are regarding the underlying feature? As far as I understand this is a top requested <https://2019.stateofcss.com/opinions/#missing-features> feature from authors. Thanks!

1 0

Re: [webkit-dev] Embedding Identifiers in Commit Messages
by Jonathan Bedard 04 Nov '20

04 Nov '20

>> On Mon, Nov 2, 2020 at 2:04 PM Jonathan Bedard <jbedard at apple.com <https://lists.webkit.org/mailman/listinfo/webkit-dev>> wrote: >> >>> We appreciate everyone’s feedback on transitioning away from Subversion to Git, I’ll be releasing >>> an expected timeline of up-coming changes in the next week before the contributors meeting. >>> >>> In the mean time, we’re preparing on adding identifiers to new commit messages, that work is >>> tracked in https://bugs.webkit.org/show_bug.cgi?id=218407. <https://bugs.webkit.org/show_bug.cgi?id=218407.> At the moment, we’re likely going to be >>> appending the identifiers to commit messages (as the current change proposes), but I wanted to >>> provide a chance for folks to object to this change before it becomes canonical. >> >> I'm a bit confused here. It looks like the patch only affects commits >> made via webkit-patch. Given there are a lot of people who don't use >> webkit-patch land, I'm not certain this strategy is sound even in the >> short term. Why don't we do this in post commit hook instead? > Yes, if your reason for switching to Git is making things easy for people using Git to contribute, > please try to use the standard Git commands as much as possible. Otherwise, from a developer experience > point of view you are still doing your custom system, and it does not matter that the backend is Git. > You can use an approach similar to the hook used for Gerrit: > https://gerrit-review.googlesource.com/Documentation/cmd-hook-commit-msg.ht… <https://gerrit-review.googlesource.com/Documentation/cmd-hook-commit-msg.ht…> > Note that this hook runs locally on developer's machine, but you can additionally have a server-side hook that > checks that the id is indeed present in the commit message, and rejects the commit otherwise (Gerrit also does > this for its Change-Id). I think it is not possible to alter the commit message from server-side with a standard > Git server, it would create confusion because the local branch from the developer machine would not match what's > on the server. > -- > Adrien. The long term plan is to have the default branch be protected and all commits go though commit-queue. This means that contributors are using the default set of git commands, but most contributors (even committers and reviewers) would not have push access to the default branch (and other “production” branches, although we need to define exactly what that means), and are instead sending pull requests to commit-queue (or merge-queue, if you prefer, it may be re-branded) to be landed. The mechanics of the current change operate on SVN, not Git. And we already rely pretty heavily on contributors using webkit-patch to land changes, trac.webkit.org <http://trac.webkit.org/> wouldn’t work well if the vast majority of contributors were not using it to land change.

1 0

User Agent Client Hints
by Yoav Weiss 03 Nov '20

03 Nov '20

Hi WebKit folks, Circling back on the previous discussion <https://lists.webkit.org/pipermail/webkit-dev/2020-May/031195.html> about User-Agent ClientHint. The feature was implemented in Chromium and is being rolled out in Chrome. There were some concerns mentioned in the previous thread, that we believe were since addressed. Would the feature be something that WebKit would consider shipping? Cheers :) Yoav

3 8

Embedding Identifiers in Commit Messages
by Jonathan Bedard 03 Nov '20

03 Nov '20

Hello WebKit contributors, We appreciate everyone’s feedback on transitioning away from Subversion to Git, I’ll be releasing an expected timeline of up-coming changes in the next week before the contributors meeting. In the mean time, we’re preparing on adding identifiers <https://trac.webkit.org/wiki/commit-identifiers> to new commit messages, that work is tracked in https://bugs.webkit.org/show_bug.cgi?id=218407 <https://bugs.webkit.org/show_bug.cgi?id=218407>. At the moment, we’re likely going to be appending the identifiers to commit messages (as the current change proposes), but I wanted to provide a chance for folks to object to this change before it becomes canonical. Our intention is also to edit history in the Git clone to embed these identifiers to historical commits, but there is some disagreement on that intention, and that task will be tracked separately. Thanks, Jonathan

3 2