May 2021 - webkit-dev - lists.webkit.org

Request for position: UA-CH API Updates
by Mike Taylor 12 May '21

12 May '21

Hi there WebKit folks, I'm writing to request a position on some recent API updates to the User-Agent Client Hints API. There's a blink-dev I2P on the topic at [1], but I'll repeat the updates here: ** **1. Sec-CH-UA-Bitness: adds a new high-entropy hint to expose the OS bitness, which may be combined with Sec-CH-UA-Arch to provide optimized binaries for download, for example.** * *Spec PR: https://github.com/WICG/ua-client-hints/pull/210. In the linked issue Maciej mentioned[2] that were Apple to implement this, it may just send the empty string or a fixed value (which are valid values, per spec). * * 2. Make Sec-CH-UA-Platform a low-entropy hint: OS is passively observable at the TCP level anyways, so we plan to change this to be low-entropy and send as a default header (similar to Sec-CH-UA and Sec-CH-UA-Mobile). Spec PR: https://github.com/WICG/ua-client-hints/pull/221 3. Include low-entropy hints by default in UADataValues (returned by getHighEntropyValues()). If a hint moves from high to low-entropy, this future proofs any code relying on it. Spec PR: https://github.com/WICG/ua-client-hints/pull/226 4. Add a toJSON method to NavigatorUAData’s IDL. Technically a bugfix, but it is an API change (instead of returning {}, JSON.stringify(navigator.userAgentData)) will now be useful) Spec PR: https://github.com/WICG/ua-client-hints/pull/228 ** (For context, Maciej provided a review previously in https://lists.webkit.org/pipermail/webkit-dev/2020-November/031571.html and filed a lot of great issues. 2 remain open: issues 151 and 148) [1] <https://groups.google.com/a/chromium.org/g/blink-dev/c/dafizBGwWMw/m/72l-1z…> [2] <https://github.com/WICG/ua-client-hints/issues/105#issuecomment-626904363> thanks, Mike

1 0

Request for Position: Pickling for Async Clipboard API
by Anupam Snigdha 11 May '21

11 May '21

Hi webkit-dev, This is a request for Webkit's position on Pickling for Async Clipboard API feature: Explainer: https://github.com/dway123/clipboard-pickling/blob/main/explainer.md#pickli… There have been discussions on Pickling Clipboard API during TPAC and also while discussing Raw Clipboard API. Slides: https://docs.google.com/presentation/d/1_fAgL54D0whQ497G8iL0K2kKpxiWDr3M7gX… Editing TF Minutes: https://lists.w3.org/Archives/Public/public-editing-tf/2020Oct/0017.html Chrome Status entry: https://chromestatus.com/feature/5649558757441536 Please let us know if you have any feedback! Thanks, Anupam

1 0

Request for Position: Compute Pressure API
by Olivier Yiptong 06 May '21

06 May '21

Hello WebKit devs, We'd like to get WebKit's position on the Compute Pressure API. Description: We propose a new API that conveys the utilization of CPU resources on the user's device. This API targets applications that can trade off CPU resources for an improved user experience. For example, many applications can render video effects with varying degrees of sophistication. These applications aim to provide the best user experience, while avoiding driving the user's device in a high CPU utilization regime. High CPU utilization is undesirable because it strongly degrades the user experience. Many smartphones, tablets and laptops become uncomfortably hot to the touch. The fans in laptops and desktops become so loud that they disrupt conversations or the users’ ability to focus. In many cases, a device under high CPU utilization appears to be unresponsive, as the operating system may fail to schedule the threads advancing the task that the user is waiting for. Thanks! - Specification Title: Compute Pressure API - Specification URL: https://oyiptong.github.io/compute-pressure/ - Explainger: https://github.com/oyiptong/compute-pressure/blob/main/README.md - ChromeStatus.com entry: https://chromestatus.com/features/5597608644968448 - TAG design review request: https://github.com/w3ctag/design-reviews/issues/621 - Mozilla Request for Position: https://github.com/mozilla/standards-positions/issues/521

3 5

JPEG XL support?
by Sami Boukortt 06 May '21

06 May '21

Hello WebKit developers, I am Sami from the team at Google+Cloudinary that is working on JPEG XL <https://en.wikipedia.org/wiki/JPEG_XL>. We are making good progress on our integration in the Chrome browser <https://crbug.com/1178058>, and we would be delighted if there were support for it in WebKit as well, to make JPEG XL useful to more users. There appears to be growing interest in using the format (~100 stars on the Chrome bug), including from Facebook (comment #16). So, we wonder: would you be open to an implementation of JPEG XL decoding in WebKit using the reference implementation <https://gitlab.com/wg1/jpeg-xl>? Many thanks. Best regards, Sami Boukortt on behalf of the libjxl team

3 2

Request for position: New Canvas 2D API
by Aaron Krajeski 05 May '21

05 May '21

Hi webkit-dev, This is a request for WebKit's position on New Canvas 2D API <https://github.com/fserb/canvas2D/blob/master/rationale.md> features. Explainer/Chrome Dev Summit Video https://github.com/fserb/canvas2d https://youtu.be/dfOKFSDG7IM Summary Updated functionality for the Canvas2D API. Adds nine new features/functions to CanvasRenderingContext2D: - "ContextLost" and "ContextRestored" events - "willReadFrequently" option for canvases where lots of readback is expected - CSSColorValues as style inputs - More CSS text modifier support - A reset function - A roundRect draw primitive - Full 4x4 transformation matrices - Conic gradients - Better support for SVG filters Contact emails aaronhk(a)chromium.org, fserb(a)chromium.org *Spec and tests* - WHATWG spec in progress: Text Modifiers <https://github.com/whatwg/html/pull/6560> Filters <https://github.com/web-platform-tests/wpt> Perspective Transforms <https://github.com/whatwg/html/issues/5620> reset() <https://github.com/whatwg/html/issues/5618> CSSColorValue <https://github.com/whatwg/html/issues/5616> willReadFrequently <https://github.com/whatwg/html/issues/5614> RoundRect <https://github.com/whatwg/html/issues/5619> ConicGradient <https://github.com/whatwg/html/issues/5431> Context Loss <https://github.com/whatwg/html/issues/4809> - MDN spec Conic gradient <https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/c…> Text Modifiers <https://github.com/GoogleChromeLabs/puppy-content/pull/23> (via ChromeLabs/puppy-content) - Web platform tests RoundRect <https://github.com/web-platform-tests/wpt/tree/7b0ebaccc62b566a1965396e5be7…> reset() <https://github.com/web-platform-tests/wpt/tree/master/html/canvas/element/r…> Perspective Transforms <https://github.com/web-platform-tests/wpt/tree/master/html/canvas/element/t…> Context Loss <https://source.chromium.org/chromium/chromium/src/+/master:third_party/blin…> (this is not testable on WPT) Filters <https://github.com/web-platform-tests/wpt/tree/master/html/canvas/element/s…> CSSColorValue Input <https://chromium-review.googlesource.com/c/chromium/src/+/2794982> WillReadFrequently <https://source.chromium.org/chromium/chromium/src/+/master:third_party/blin…> (testable in WPT, work in progress to add tests there) Conic Gradient <https://github.com/web-platform-tests/wpt/blob/master/html/canvas/element/f…> Text Modifiers <https://github.com/web-platform-tests/wpt/tree/master/html/canvas/element/d…> - Chrome Status <https://chromestatus.com/feature/6051647656558592> Look forward to hearing your feedback! Cheers! Aaron

3 2

New EWS Non-Unified builder
by dpino 04 May '21

04 May '21

Hi everyone, In Igalia we have been discussing the need of deploying a new builder which builds WebKit using non-unified sources, and we know that at least the folks at Sony are also in favor. One side effect of Unified Source building is that it hides compilation errors. The kinds of errors that usually get hidden by unified builds are missing headers inclusions and missing definitions of functions declared inline; the latter being tricky to debug because it results in mysterious linker errors. This is caused by unified builds stashing several .cpp files together for compilation, so the definitions and header inclusions done in one “leak” into the others. As for missing header inclusion errors, a source file might include a header definition as a co-lateral effect of being stashed together with another file that indeed includes the missing header. These hidden compilation errors may arise later at some point if unified source files are stashed together in a different manner. The current situation is requiring periodical maintenance. You can check build fixes commits due to unified source compilation with: $ git log --pretty=short --grep "Non-unified" Here are some examples: https://bugs.webkit.org/show_bug.cgi?id=222652 https://bugs.webkit.org/show_bug.cgi?id=222755 https://bugs.webkit.org/show_bug.cgi?id=221701 A new builder which builds WebKit with non-unified Source will highly help to improve this situation. Compilation errors will be detected as soon as possible and will save a lot of time not only for the developers who are currently doing this manual maintenance but for anyone who would like to build WebKit, and may stumble on compilation errors accidentally introduced due to unified sources. While correct compilation of the codebase can only be guaranteed with non-unified source builds, we do not propose switching the current EWS compilation builders to non-unified because it's slower and the EWS LayoutTests and API test bots use the products built by the EWS builders — we do not want to delay getting results from those. That's why we are proposing a new builder: it will run on parallel, resulting in no slowdown for the other EWS builders, which will keep using unified builds. How this new builder will impact developers? The EWS LayoutTest bots take at least 1 hour to complete a build. We think that as long as this new EWS Non-Unified builder is within that time budget, this new EWS wont' slow down development speed. Thoughts? Best regards, Diego

14 23

Request for Position: COLR v1 Vector Color Fonts
by Dominik Röttsches 03 May '21

03 May '21

Hi, This is a request for WebKit's position on COLR v1 vector color fonts. Spec: https://github.com/googlefonts/colr-gradients-spec/blob/main/OFF_AMD2_WD.md *Proposed changes to ISO/IEC 14496-22 (Amendment 2)* Chromium Bug: https://crbug.com/1170733 Summary: COLR v1 fonts are a new vector color font format that provides gradients, transforms and compositions for font glyph drawing enabling an expressive, very compact glyph definition format for OFF/OpenType fonts. This format provides size and rendering fidelity (scaling) advantages over bitmap fonts such as SBIX, CBDT/CBLC fonts for glyph designs that lend themselves well to being encoded as vector art. Thank you in advance for your position statement on this topic, Dominik

2 2

Request for opinion: Private Network Access secure context restriction
by Titouan Rigoudy 03 May '21

03 May '21

Hi there friendly WebKittens, I am gearing up to ship a small first step of Private Network Access [1] in Chromium. Roughly: Websites served over HTTP from public IP addresses will no longer be allowed to make subresource fetches to private IP addresses (RFC1918 and/or localhost). Specifically, this restriction applies to non-secure contexts. Secure contexts are unaffected by this change. We have metrics in place telling us that ~0.1% of page visits at most make use of this feature. I am interested in WebKit's opinion on this matter. For more details, see the chromestatus entry [2] and the Intent to Ship thread on blink-dev(a)chromium.org [3]. Cheers, Titouan [1] https://wicg.github.io/private-network-access/ [2] https://chromestatus.com/feature/5436853517811712 [3] https://groups.google.com/a/chromium.org/g/blink-dev/c/cPiRNjFoCag/m/DxEEN9…

2 2

Request for position: Declarative Link Capturing
by Matt Giuca 03 May '21

03 May '21

Hi WebKit developers, We are interested in the WebKit position on a proposed extension to the Web App Manifest. Specification Title: Declarative Link Capturing (capture_links) Specification or proposal URL: https://github.com/WICG/sw-launch/blob/main/declarative_link_capturing.md TAG review: w3ctag/design-reviews#589 Chrome Status: https://www.chromestatus.com/feature/5734953453092864 Mozilla Standards Position: https://github.com/mozilla/standards-positions/issues/520 Description: Extension to the Web App Manifest spec, adding a single new member capture_links, controlling the behaviour of the installed web application when the user clicks links within its scope from a web browser or another application in the OS. Thanks Matt Giuca (Google)

1 1