April 2022 - webkit-dev - lists.webkit.org

Re: [webkit-dev] ChangeLog Deprecation Plans
by Ryosuke Niwa 18 Apr '22

18 Apr '22

On Mon, Apr 18, 2022 at 13:34 Ryosuke Niwa <rniwa(a)webkit.org> wrote: > > On Mon, Apr 18, 2022 at 08:30 Jonathan Bedard via webkit-dev < > webkit-dev(a)lists.webkit.org> wrote: > >> As we migrate WebKit from Subversion to git, I would like to migrate the >> project away from ChangeLogs. The reason for this is that ChangeLogs make >> some of the features of git hard to use, namely, cherry-picking commits >> between branches requires conflict resolution every time. Rotating >> ChangeLogs is also moderately difficult in git with locked down commit >> access like our project has, only repository administers would, in >> practice, be able to rotate ChangeLogs. Lastly, ChangeLogs are uncommon in >> git based projects, so new contributors will find them difficult to manage. >> >> Currently, our git tooling makes very little effort to either support >> ChangeLogs or to provide alternatives. I have listed bellow some of the >> reasons I understand folks to like ChangeLogs along with possible git-based >> solutions, if necessary. >> >> 1) Subversion commit messages are stored server side, local development >> needs a copy >> git doesn’t have this problem. We have a local record of commit messages >> in every checkout. >> 2) We need a way to comment on commit messages in review >> Current tooling sets the pull request description as the commit message, >> “Quote Reply” kind of provides a way to inline comment, although it’s not >> the formal review UI >> *Proposal*: Tooling should support a “COMMIT_MESSAGE” file in each pull >> request commit that becomes COMMIT_MESSAGE when a pull request is landed >> 3) Edit commit messages while creating a change, not just when committing >> the change >> The “overwrite” workflow already sort of support this idea by using amend >> commits instead of appending commits to an existing branch >> *Proposal*: The above “COMMIT_MESSAGE” file workflow would allow >> iterative building of a commit message before committing >> > > There is another issue to add here. Right now, change log entry exists for > many sub directories of the respiratory like Source/WebCore and > LayoutTests. With a commit message, however, there could be only one per > patch / PR. > > This makes it harder to review each part separately. For example, I'd like > to focus on core changes first and then onto test changes, or vice versa > depending on patches I'm reviewing. > > So ideally, this commit message field mirror where change log files > currently exist such that "commit message" for each sub directory will show > up separately. > > 4) Using git commands to view commit messages is hard >> There don’t seem to be many projects which have a solution for this. In >> practice, it seems that reducing the scope of messages shown by restricting >> history to a specific directory or even file is one solution, another is >> shorter commit messages >> *Proposal*: Have Tools/Scripts/git-webkit setup configure hooks in >> contributors local git repositories to lay down CommitMessages.history >> files on merge, checkout and commit which contain the last 5000 commit >> messages. We can put these in similar places to where ChangeLogs are today, >> although we would likely want them in fewer places because this will >> increase local compute time on many git operations. We could also make this >> a configurable setting so that engineers who are more comfortable with the >> raw command line tooling do not have to deal with slower git operations. >> >> I like the COMMIT_MESSAGE and hooks proposals because they are opt-in. >> Contributors who wish to use native git tooling to contribute and interact >> with the project do not have to use either tool, but the tools are >> compatible enough with native git workflows that contributors who find >> editing and viewing commit messages primarily in a text editor >> >> Looking forward to the discussion, >> >> Jonathan Bedard >> WebKit Continuous Integration >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev(a)lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> > -- > - R. Niwa > -- - R. Niwa

1 0

Request for Position: PWA File Handling API
by Evan Stade 14 Apr '22

14 Apr '22

Hello WebKit leads, The File Handling API is a proposed spec addition to the PWA Manifest that allows apps to register with the operating system as file handlers. Explainer: https://github.com/WICG/file-handling/blob/main/explainer.md Outreach: https://web.dev/file-handling/ Spec change (in incubations): https://github.com/WICG/manifest-incubations/pull/51 It has undergone developer trial and origin trial in Chromium with positive developer feedback. PTAL when you get a chance. -- Evan Stade

1 1

Request for position: Web App Dark Mode
by Louise Brett 14 Apr '22

14 Apr '22

Hi, I am requesting a standards position signal on Web App Dark Mode. This allows web apps to set a dark mode theme color and background color in their manifest. Explainer: https://github.com/WICG/manifest-incubations/blob/gh-pages/user-preferences… Chromestatus: https://chromestatus.com/feature/5714780426862592 Thanks, Louise (Chrome OS web apps platform team)

1 0

Request for Position: Multi-Screen Window Placement API
by Ben Morss 12 Apr '22

12 Apr '22

Hi all, We'd love to get WebKit's position on the new Multi-Screen Window Placement API. The proposal is to make incremental improvements to existing screen information and window placement APIs, allowing web applications to be intentional about the experiences they offer to users of multi-screen devices. We'd like to make it simple to: - detect when screen properties changes - discover the presence of extended screen areas - request extended screen information - place a window on a specific screen - show a window fullscreen on a specific screen This is useful for applications like the following: - a slideshow app shows slides full-screen on a projector, while displaying speaker notes on a laptop - a creativity app pops up secondary windows, like palettes, on a separate screen - a videoconferencing app shows video on a large screen, and controls on a smaller screen - a medical app shows images on multiple displays - a financial app shows dashboards on multiple monitors Future work could involve support for foldable devices, showing a window that spans multiple screens, etc. For more details, please see these links: - Explainer: https://github.com/webscreens/window-placement/blob/main/EXPLAINER.md - Draft Community Group Report: https://webscreens.github.io/window-placement/ - Additional ideas: https://github.com/webscreens/window-placement/blob/main/additional_explora… Thanks for your feedback on this! All best, Ben

1 1

WebKit and GitHub Update
by Jonathan Bedard 12 Apr '22

12 Apr '22

It is now the time to start widespread testing of pure git checkouts for WebKit. Commit queue has been reimplemented for GitHub, so you don't need a Subversion or git-svn checkout for changes to trunk/main that aren’t modifying SVN properties. Over the past few months, we’ve been working on transitioning the WebKit project away from Subversion and to `git` hosted by GitHub. While we still have a few weeks of work left, we wanted to announce that the WebKit project now supports GitHub pull-requests for developing, reviewing and landing changes. We’d like to encourage folks to try out these new workflows to identify bugs and provide feedback. To get started, migrate your local WebKit checkouts to the GitHub version (documentation is available at https://github.com/WebKit/WebKit/wiki/Migration <https://github.com/WebKit/WebKit/wiki/Migration>), review our GitHub contribution documentation at https://github.com/WebKit/WebKit/wiki/Contributing#contributing-code <https://github.com/WebKit/WebKit/wiki/Contributing#contributing-code>, and start creating some pull requests! We will be collecting bugs and feedback under our umbrella bug, https://bugs.webkit.org/show_bug.cgi?id=239082 <https://bugs.webkit.org/show_bug.cgi?id=239082>. It is worth noting that while we are currently displaying EWS results via GitHub’s native checks UI, we have a plan underway to add a dynamic comment belonging to EWS that will contain information similar to the bubbles on bugs.webkit.org <http://bugs.webkit.org/>. Lastly, we have no plans yet to deprecate patch workflows. As mentioned in the migration documentation, `webkit-patch` will continue to work inside GitHub checkouts, so it is possible to use both the pull-request workflow and patch workflow from the same checkout. Jonathan Bedard WebKit Continuous Integration

2 2

Position on new syntax in mediaqueries-4
by Anders Hartvoll Ruud 12 Apr '22

12 Apr '22

For example, in mediaqueries-4 you can do e.g. @media (width >= 100px) rather than @media (min-width: 100px). In addition, the spec level adds support for 'not' (in other places than just the start), 'or', nesting and <general-enclosed>/unknown handling. Do you have any plans to implement this? (Or plans to _not_ implement). Relevant Webkit bug: https://bugs.webkit.org/show_bug.cgi?id=180234 Thanks, Anders

2 2

Request for position: Local Font Access
by Joshua Bell 08 Apr '22

08 Apr '22

This is a request for WebKit's position on introducing an API that allows sites to request access to local font data, for use with content authoring tools that use custom text stacks. Links: * Explainer: https://github.com/WICG/local-font-access/ * Spec: https://wicg.github.io/local-font-access/ * ChromeStatus: https://chromestatus.com/feature/6234451761692672

2 2

Request for position: Topics API
by Josh Karlin 06 Apr '22

06 Apr '22

Hi WebKit-Dev, We've been working on the Topics API that allows for interest-based advertising in a browser ecosystem in which storage is partitioned by top-frame site. This API replaces our first proposal in this area, FLoC. We would like to hear what you think about it. Note that Chrome is implementing (with spec following shortly after) but we're quite open to evolving the API over time and are appreciative of your feedback. explainer: https://github.com/jkarlin/topics chromestatus: https://chromestatus.com/feature/5680923054964736 spec: TBD Thank you, Josh

2 1

Miguel Gomez is now WebKit reviewer
by Carlos Garcia Campos 04 Apr '22

04 Apr '22

Hi, I'm happy to announce that Miguel Gomez is now WebKit reviewer. Miguel has a lot of experience in WebKitGTK and WPE graphics, so he is the perfect reviewer now for graphics related patches for GTK/WPE. Please join me in congratulating Miguel! Carlos

2 1

Request for Position: Cross-Origin-Resource-Blocking (CORB)
by Patrick Griffis 02 Apr '22

02 Apr '22

Hi everybody, I'd like a position on CORB and intend to implement it in the future. This is already part of the Fetch Standard[0] and should be relatively straightforward. It effectively blocks cross-origin requests for resources they don't make sense in their context. For example an `img` element should never get a response that contains HTML and in that case will not return the HTML data. This can prevent unintentional data leaks. This is implemented by Chromium for years now and I don't believe will be invasive. [0] https://fetch.spec.whatwg.org/#corb

2 3