May 2020 - webkit-dev - lists.webkit.org

Position on WebXR Anchors Module
by Piotr Bialecki 29 May '20

29 May '20

Hello, WebKit! I'd like to ask for WebKit's position on WebXR Anchors Module. It is an extension of WebXR Device API, the standardization efforts are happening in the Immersive Web Community Group. In short, the API would allow web applications to ask the underlying XR systems to track particular real world poses over time & query for the latest pose as the system's understanding of the real world evolves - more details can be found in the explainer and the specification draft. Explainer: https://github.com/immersive-web/anchors/blob/master/explainer.md Spec draft: https://immersive-web.github.io/anchors/ TAG review: https://github.com/w3ctag/design-reviews/issues/479 Could I get your position on this? Thanks, Piotr Bialecki

1 0

Position on emerging standard: HTMLLinkElement "disabled" attribute behavior
by Mason Freed 28 May '20

28 May '20

Hi WebKit, I would like to request an official WebKit position on the changes to the HTMLLinkElement "disabled" attribute behavior, as discussed here: https://github.com/whatwg/html/issues/3840. The interop situation here is not great, so it would be good to align on a single spec. I would like to ship the behavior specified in https://github.com/whatwg/html/pull/4519 in Chromium, and Gecko already ships this behavior. Thanks, Mason Freed

1 0

Request for position on First-Party Sets
by Lily Chen 27 May '20

27 May '20

Hi WebKit-dev, We are requesting WebKit's position on the First-Party Sets proposal as described in the explainer [1]. Feedback [2] was provided on a previous version of the proposal, which has since been revised. The TAG review thread is here [3]. Thanks! [1] Explainer: https://github.com/krgovind/first-party-sets [2] Previous feedback: https://github.com/krgovind/first-party-sets/issues/6 [3] TAG review: https://github.com/w3ctag/design-reviews/issues/342

2 1

Request for position on named pages and page-orientation
by Morten Stenshorne 26 May '20

26 May '20

Hello, WebKit! I'm asking for WebKit's position on the new page-orientation descriptor [1] to be used in @page rules. This is currently being prototyped in Chromium, along with support for named pages [2]. The page-orientation descriptor isn't very meaningful without support for named pages (unless we're happy with @page :first, @page :left, etc.), so we're doing both at the same time. [1] https://drafts.csswg.org/css-page-3/#page-orientation-prop [2] https://drafts.csswg.org/css-page-3/#using-named-pages Explainer: https://github.com/mstensho/page-orientation/ TAG review: https://github.com/w3ctag/design-reviews/issues/515 Chromium intent to prototype: https://chromestatus.com/features/5173237715566592 Any thoughts? -- Morten Stenshorne, Software developer, Blink/Layout, Google, Oslo, Norway

1 0

Best approach to solve bug 202233
by Majo Vlasanovich 18 May '20

18 May '20

Hi! I'm trying to solve this bug https://bugs.webkit.org/show_bug.cgi?id=202233. I don't know if this is the place but I wanted to talk a little bit about possible approaches. The way I have thought on how to do this is: In MediaRecorder::startRecording(Optional<int> timeslice), every few seconds (the time pass in timeslice) execute the code in MediaRecorder:: stopRecording()with some modifications. There are some things to figure it out but do you think is the best approach or have any other ideas? Thanks!

1 0

Platform.h vs. makefiles
by Darin Adler 11 May '20

11 May '20

Hi folks. The Platform.h configuration file family has been useful for WebKit for a long time. We created it to try to organize configuration options in WebKit so the would not be spread out through the whole project. One way to look at these, particularly the ENABLE options, is as a set of configuration options that let each consumer of the WebKit source code create a unique flavor of WebKit with the particular features they want enabled turned on and others turned off. Another is to think of this as a mechanism for keeping decisions made by the WebKit contributors organized and easy to understand. If these truly are WebKit consumer options, then it’s important they be set as part of the build process. The macros can be defined with a build and configuration system outside WebKit, and the Platform.h headers should interpret those values correctly. On the other hand, if we are just trying to keep our decisions straight, then it would be best if the logic for what is on and what is off by in the header files, written with preprocessor macro logic, and not spread across multiple make files and scripts. Thus I think the pattern on macOS, for example, of setting these in .xcconfig files doesn’t make a lot of sense. I think the .xcconfig files should compute the things that need to be determined about the build environment, but the configuration decisions should be in files like PlatformHaveCocoa.h, for example. I think the guideline should be like this: All code to compute configuration should be in the Platform.h files, not in makefiles, with only the following exceptions: 1) Options like ENABLE(XXX) that some ports wish to offer as options to people building WebKit can have overridden values in makefiles. But even these options should have sensible defaults in the Platform.h headers that express the current status of the port from the point of view of the port’s maintainers. Ideally we’d find a way to not repeat these default settings twice. 2) In some cases, the build machinery needs to contribute to things like feature detection. So on some platforms, things like HAVE(READLINE) would be set correctly by the build system. Options intended to be set by the environment would carefully be wrapped in #ifndef. But other options, which simply express relationships between configuration elements, are designed to be set by Platform.h and not overridden by the environment, and so they would not be wrapped in #ifndef. Many HAVE options and most USE options would fall into this category. What do you all think? — Darin

4 6

PSA: EWS bots aperez-{gtk, wpe}-ews offline for some days
by Adrian Perez de Castro 11 May '20

11 May '20

Hello, Unfortunately, builders “aperez-gtk-ews” and “aperez-wpe-ews” will be offline for a few days: it is sitting at the office, where nobody is going these days, and I cannot get hold of it remotely. Next time I venture out I plan to stop by and bring it back online—but that may take until May 11th. Meanwhile, the remaining EWS bots for the GTK and EWS bots seem to be handling the workload just fine, so it does not seem like this will be an inconvenience for now. My apologies for this. Cheers, —Adrián

1 1

Position on User-Agent Client Hints
by Yoav Weiss 08 May '20

08 May '20

Hey WebKit folks, I'd like to ask for your official position on the User Agent Client Hints <https://wicg.github.io/ua-client-hints/> specification. +Maciej Stachowiak <mjs(a)apple.com> has been providing great feedback on the proposal, as well as to the underlying Client Hints Infrastructure <https://wicg.github.io/client-hints-infrastructure/> (in its former iterations), which helped shape those proposals, but that obviously doesn't count as endorsement. There's an intent to ship for the feature <https://groups.google.com/a/chromium.org/d/msg/blink-dev/A4wxFpvqUfA/g7iccl…> over at blink-dev, and your position would be appreciated as input into that process. Thanks :) Yoav

5 6

PSA: Changes in the recommended GTK/WPE developer workflow
by Philippe Normand 07 May '20

07 May '20

Hi, Until now the most recommended way to work on the GTK and WPE ports was to use a custom JHBuild[0] moduleset ([1][2]) for build/runtime dependencies. This setup was deployed almost 10 years ago [3] and while it is an opt-in approach, it is highly recommended, especially if you want to run layout tests locally. If you ever executed Tools/Scripts/update-webkitgtk-libs or Tools/Scripts/update-webkitwpe-libs it means you currently have a DependenciesGTK and/or DependenciesWPE folder in WebKitBuild/ and that your workflow is JHBuild-based. JHBuild has various shortcomings, even though it served us well all these years: - if the moduleset is modified, the bots remove the whole Dependencies{GTK,WPE} folders and rebuild everything from scratch - no cross-compilation support - no clear separation between the host system and the JHBuild-based sysroot - poor system requirements management (See the install-dependencies scripts in Tools/{wpe,gtk}) - time lost rebuilding the dependencies (can take up to an hour on my build machine) So in order to improve our lives a bit, we decided to try a new workflow, this time based on Flatpak[4]. Instead of having every developer locally build the dependencies, the built sysroot will be packaged in a Flatpak SDK/Runtime and downloaded to the developer machine. Currently the SDK is built for X86_64 but additional architectures can be supported (ARMv7, Aarch64 at least). The advantages of this new approach: - cross-compilation can easily be achieved - clear separation between the host system and the SDK sysroot - the SDK runs in a sandbox - unified toolchain for WebKit build (currently both GCC 9.2.0 and clang 8.0.1) - no time lost rebuilding dependencies :) - consistent layout tests coverage across different hosts - separate build directories for each port (example: WebKitBuild/GTK/Release mounted as /app/WebKit/WebKitBuild/Release in the SDK sandbox) As a bonus, this setup allows for: - integration with sccache, for faster WebKit builds - builtin IceCC support without additional manual steps (you still need a scheduler running on the host system though) The only disadvantage of this new approach is that hacking on dependencies is currently not trivial to accomplish. We plan to enable this most likely via the Flapjack[5] tool. Once the patch from bug#205658 [6] lands, this workflow will be available. How do I use it? Easy: 1. Make sure your flatpak version is recent enough, 1.4.4 is the minimum version we support. Backports for Debian stable are available and for Ubuntu LTS, a PPA is available. See the Flathub instructions (though you don't need to manually add the flathub remote) [7]. 2. Run update-webkitgtk-libs or update-webkitwpe-libs as usual. This will download and install the SDK in WebKitBuild/UserFlatpak/ 3. Run build-webkit as usual The SDK will be used when running the tests (API, layout, webkitpy, etc) and the MiniBrowser. For the time being we keep the JHBuild workflow in the SVN, although if everything goes well, it will be removed in the coming months. Hence we encourage all GTK/WPE developers to try this new workflow! If you still want to keep using JHBuild, make sure to set the WEBKIT_JHBUILD=1 environment variable in your shell. But keep in mind that we intend to remove support for JHBuild if Flatpak works as expected (so please try to test it, and report any issue with it). The GTK/WPE buildbots and EWS are currently running with JHBuild and will be switched one-by-one to Flatpak soon. The SDK sources are currently hosted on Github[8], but we might move them to WebKit's SVN. Philippe [0] https://developer.gnome.org/jhbuild/stable/ [1] https://trac.webkit.org/browser/trunk/Tools/gtk/jhbuild.modules [2] https://trac.webkit.org/browser/trunk/Tools/wpe/jhbuild.modules [3] https://bugs.webkit.org/show_bug.cgi?id=73425 [4] https://flatpak.org/ [5] https://github.com/endlessm/flapjack [6] https://bugs.webkit.org/show_bug.cgi?id=205658 [7] https://flatpak.org/setup/ [8] https://github.com/igalia/webkit-flatpak-sdk

1 2

Position on emerging standard: WebCodecs
by Dan Sanders 06 May '20

06 May '20

Hello, I'm reaching out to see if WebKit would like to weigh in on the WebCodecs WICG proposal: https://discourse.wicg.io/t/webcodecs-proposal/3662. The WebCodecs API enables web developers to instantiate codecs (audio/video encoders/decoders) and use them to process individual frames. There is a related proposal for image decoders; it enables access to individual animation frames: https://discourse.wicg.io/t/proposal-imagedecoder-api-extension-for-webcode…. An implementation of these APIs is being developed in Chromium. Thank you, Dan Sanders

2 3