March 2021 - webkit-dev - lists.webkit.org

github.com repository force push
by Aakash Jain 19 Mar '21

19 Mar '21

Hi everyone, We had little bit of issue with syncing between WebKit's github and svn repositories. To fix the issue, we had to force push and modify few git commits. In case you notice any conflict in your github.com <http://github.com/> checkout of WebKit repo (which might be because of having one of those commits which we modified), please do the following: "git reset --hard HEAD~100", "git pull". Please let me know if you face any issues. Thanks Aakash

1 0

Re: [webkit-dev] Build bot workers aperez-{wpe, gtk}-ews to be offline for a week
by Adrian Perez de Castro 19 Mar '21

19 Mar '21

On Tue, 16 Mar 2021 02:18:48 +0200 Adrian Perez de Castro <aperez(a)igalia.com> wrote: > On Sat, 06 Mar 2021 16:29:10 +0200 Adrian Perez de Castro via webkit-dev <webkit-dev(a)lists.webkit.org> wrote: > > > I will be moving to a new office in the next week or two, and I need to shut > > these down today. In all goes as expected, it should be possible to bring them > > online in about a week. There are other workers for the GTK and EWS ports, so > > the queues will continue running normally--if a tad slower. In the meantime, > > my apologies for the inconvenience. > > The hardware was moved on Saturday, and I am currently waiting that Internet > connectivity is sorted out to be able to bring the builders back online in > the next days. …aaand they are back online. Cheers, -Adrian

1 0

Announcement: Adding WebKit 2 Debug and Apple Silicon EWS Queues
by Matt Lewis 18 Mar '21

18 Mar '21

Hello WebKit, I would like to let everyone know that as of today you will see new bubbles on each of your patches. We have added support in EWS for Debug WebKit 2 and Apple Silicon. Happy Coding, Matt Lewis

1 0

Request for position: Aligning high-resolution timer granularity to cross-origin isolated capability
by Yoav Weiss 18 Mar '21

18 Mar '21

Hey folks, We recently changed <https://github.com/w3c/hr-time/pull/93> the HR-time spec <https://w3c.github.io/hr-time/> to better align its resolution clamping with cross-origin isolated capability <https://html.spec.whatwg.org/multipage/webappapis.html#concept-settings-obj…>, and now I'm interested in shipping this change in Chromium. In practice that means that Chromium would be reducing its resolution in non-isolated contexts (regardless of the platform's site-isolation status) to 100 microseconds, and increasing it in cross-origin isolated contexts (even in platforms without site-isolation, e.g. Android) to 5 microseconds. As WebKit already clamps those timers to 1ms (AFAIK), I'd mostly like your position on the latter. Would y'all be interested in increasing timer granularity in contexts which have guarantees against pulling in cross-origin resources without their opt-in? I'd appreciate your thoughts on the matter. Cheers :) Yoav

3 3

Request for Position on Sanitizer API
by Daniel Vogelheim 16 Mar '21

16 Mar '21

Hello webkit-dev, I'd like to request a position statement on the proposed Sanitizer API <https://github.com/WICG/sanitizer-api/>. The Sanitizer API wants to build an HTML Sanitizer right into the web platform. The goal is to make it easier to build XSS-free web applications. The intended contributions of the Sanitizer API are: Making a sanitizer more easily accessible to web developers; be easy to use and safe by default; and shift part of the maintenance burden to the platform. Currently available are an explainer <https://github.com/WICG/sanitizer-api> and an early spec draft <https://wicg.github.io/sanitizer-api/>, and early prototype implementations in Chromium & Firefox <https://github.com/WICG/sanitizer-api/blob/main/faq.md#can-i-use-the-saniti…>, behind flags. Thank you for your consideration! Daniel

2 1

Request For Position on CSS containment
by Rob Buis 15 Mar '21

15 Mar '21

Hi webkit-dev, This is a request for WebKit's position on CSS containment. Our first interest is to implement the contain property as specified here: https://www.w3.org/TR/css-contain-1/ After that, we want to work on style containment and the content-visibility property: https://www.w3.org/TR/css-contain-2/ Regards, Cathie and Rob.

2 4

Alicia Boya as new reviewer
by Xabier Rodríguez Calvar 15 Mar '21

15 Mar '21

Hi, It's my pleasure to announce that my colleague Alicia Boya has earned the reviewer status. I'm sure she will be a wonderful reviewer. Well done Alicia! 👏️ Best regards.

3 2

Request for position: ES modules for Service Workers
by Ghazale Hosseinabadi 12 Mar '21

12 Mar '21

Hi webkit-dev, This is a request for WebKit's position on ES modules for Service Workers. Explainer: https://github.com/w3c/ServiceWorker/commit/6d9500e99e764c12b117c63d10107e0… Spec: https://w3c.github.io/ServiceWorker <https://w3c.github.io/ServiceWorker/#navigator-service-worker-register%20(s…> (see "type" in the section) Existing Chromium bug:https://bugs.chromium.org/p/chromium/issues/detail?id=824647 Summary: JavaScript will support modules in service workers. Setting 'module' type by the constructor's type attribute, worker scripts are loaded as ES modules and the import statement is available on worker contexts. Thank you, Ghazale Hosseinabadi

2 1

Request for position: class static blocks
by Shu-yu Guo 12 Mar '21

12 Mar '21

Hi WebKit folks, The class static blocks proposal for JavaScript reached Stage 3 in the January TC39. The outstanding contingency at the time of stage advancement has been resolved via https://github.com/tc39/proposal-class-static-block/pull/38. Chrome is planning to ship soon. - Proposal: https://github.com/tc39/proposal-class-static-block - Specification: https://tc39.es/proposal-class-static-block/ - ChromeStatus: https://chromestatus.com/features/6482797915013120 Cheers, Shu-yu Guo, V8

1 0

Request for position on Import Conditions
by Daniel Clark 09 Mar '21

09 Mar '21

Hello WebKit-dev, I'd like to ask for WebKit's official position on import conditions, as described in the explainer at [1]. This proposal adds an inline syntax for module import statements to pass on more information alongside the module specifier. It includes support for JSON modules as a primary application, with the "type" condition used to mitigate the security issue described in [2] that previously blocked their adoption in HTML. The proposal is designed such that other conditions can be added in the future for additional use cases, some of which may not yet be anticipated. The champion group is particularly interested in your opinion on whether it's acceptable for import conditions to not be part of the module map key. The current state of our HTML spec integration PR at [3] is that they are not part of the module map key. We perform module map caching such that there will always be no more than a single fetch for a given module specifier regardless of failed module type checks. The thread at [4] discusses this issue in detail. We plan to request Stage 3 for this proposal at the upcoming TC39 meeting beginning on July 20. [1] Explainer: https://github.com/tc39/proposal-import-conditions [2] Modules MIME-type security issue: https://github.com/w3c/webcomponents/issues/839 [3] HTML Spec integration PR: https://github.com/whatwg/html/pull/5658 [4] HTML integration thread: https://github.com/whatwg/html/issues/5640 Mozilla standards-position ("worth prototyping") https://github.com/mozilla/standards-positions/issues/373 Thanks! Dan Clark

1 1