June 2020 - webkit-dev - lists.webkit.org

Request for feedback on CompressionStream and DecompressionStream
by Adam Rice 02 May '22

02 May '22

I am trying to gauge feedback on compression streams with a view to shipping them in Chromium. Very briefly, they are a way to do gzip and gunzip in the browser. Less briefly, the explainer https://github.com/WICG/compression/blob/master/explainer.md goes into some detail of the how and why. The specification https://wicg.github.io/compression/ gives verbose detail of how. You may also find the W3C TAG review https://github.com/w3ctag/design-reviews/issues/410 interesting. Any and all feedback is welcome! FAQ: Q. Will this support brotli, zstd, etc.? A. Not yet. It's on the radar. Thanks, Adam Rice, Chromium

3 3

Position on emerging standard: Declarative Shadow DOM
by Mason Freed 24 Feb '21

24 Feb '21

Hello WebKit! I would like to request an official WebKit position on the Declarative Shadow DOM proposal. There have been some great comments and discussion from WebKit folks on the issue thread, but it is a bit unclear whether the overall proposal is something WebKit would support. This was brought up and discussed, e.g., on the DOM spec PR here: https://github.com/whatwg/dom/pull/858#issuecomment-623735890 Please see below for all of the relevant supporting documents and discussions. Explainer: https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md WhatWG DOM Issue discussion: https://github.com/whatwg/dom/issues/831 HTML Spec PR: https://github.com/whatwg/html/pull/5465 DOM Spec PR: https://github.com/whatwg/dom/pull/858 TAG review: https://github.com/w3ctag/design-reviews/issues/494 Request for Mozilla Position: https://github.com/mozilla/standards-positions/issues/335 Thanks, Mason Freed

2 9

Feedback on the performance.measureMemory API proposal
by Ulan Degenbaev 14 Dec '20

14 Dec '20

Hello webkit-dev, I'd like to solicit feedback as well as an official position from Webkit on our proposal for the new memory measurement API: https://github.com/WICG/performance-measure-memory The proposal generalizes the previous performance-memory proposal [1] that was abandoned [2] due to information leak of cross-origin resources. The new API addresses the information leak and process model issues raised in the previous feedback [3]. What is different in the new API? - It relies on COOP+COEP [4] for preventing cross-origin information leaks (see "Security Considerations"). Besides security, COOP+COEP also helps implementability because the browser needs to isolate the web page from other web pages. - It does not assume any particular process model and is defined using the standard concepts such as JS agent cluster and browsing context group. - It has an extensible and generic interface for breaking down memory usage by type (JS, DOM, GPU) and owner. Implementers can choose the level of detail they are willing to provide based on their performance trade-offs (see "Performance Considerations"). Thank you, Ulan. [1]: The previous proposal: https://github.com/WICG/performance-memory/blob/master/explainer.md [2]: Information leak affecting the previous proposal: https://github.com/mozilla/standards-positions/issues/85#issuecomment-42638… [3]: Feedback from Apple on the previous proposal: https://github.com/WICG/performance-memory/issues/14 [4]: COOP and COEP explained: https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0G… Other Relevant Links Explainer: https://github.com/WICG/performance-measure-memory Open issues: https://github.com/WICG/performance-measure-memory/issues WebPerf WG F2F June 2019 presentation (for older iteration of the API): https://docs.google.com/document/d/1uQ7pXwuBv-1jitYou7TALJxV0tllXLxTyEjA2n1… TAG design review (for older iteration of the API): https://github.com/w3ctag/design-reviews/issues/386 Issue on Mozilla standards-positions: https://github.com/mozilla/standards-positions/issues/281

1 1

Request for position on Schemeful Same-Site
by Steven Bingler 30 Nov '20

30 Nov '20

Hello WebKit-dev, I'm seeking WebKit's position on Schemeful Same-Site. I've provided the explainer [1], spec [2], TAG review [3], and Blink's I2P [4] which contains some additional discussion you may find useful. Thanks, Steven [1] Explainer: https://github.com/sbingler/schemeful-same-site [2] Spec: https://mikewest.github.io/cookie-incrementalism/draft-west-cookie-incremen… [3] TAG Review: https://github.com/w3ctag/design-reviews/issues/497 [4] Blink I2P: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/qB7DKqxkiaA

3 4

Implementing MathML stylistic attributes in WebKit
by Frédéric Wang 28 Sep '20

28 Sep '20

Hello, Currently MathML attributes mathvariant, displaystyle and scriptlevel [1] [2] are implemented in WebKit using custom "style resolution" and "one-glyph rendering" inside the MathML layout code [3] [4] [5]. These features involve text rendering and interaction with CSS font-size, so it is difficult to implement them properly and completely that way. There are known bugs and missing features right now (e.g. mathvariant transform only applies to one-character strings, automatic displaystyle/scriptlevel does not work with fractions, etc) Several years ago, Gecko used to do something similar but that was causing a lot of problems (dynamic update, assertion failures...). At the end, this is now implemented in Gecko more reliably by mapping the attributes to internal CSS properties ; [6] is based on that. When I tried to do something like this in WebKit three years ago, I was only able to rely on proprietary -webkit-* extensions exposed to users [7]. So my questions are: (1) What is WebKit's mechanism to implement such stylistic attributes? (2) Is it possible to implement internal (i.e. not web-exposed to users) CSS properties/values in WebKit? (3) Is it ok to add more -webkit-* properties/values or should these properties be standardized at the CSS WG instead? I understand answers to these general questions from other browser project is either use internal properties or standardize them. Thanks, Frédéric PS: For a concrete example, see [8]. Automatic mathvariant is used for italic variables while font-size in fractions is calculated according to displaystyle / scriptlevel rules. The latter is incorrect (check the attached screenshot) while selection highlight is broken for the former. [1] https://mathml-refresh.github.io/mathml-core/#the-mathvariant-attribute [2] https://mathml-refresh.github.io/mathml-core/#the-displaystyle-and-scriptle… [3] https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/css/mathml.css [4] https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/mathm… [5] https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/mathm… [6] https://mathml-refresh.github.io/mathml-core/#css-extensions-for-math-layout [7] https://bugs.webkit.org/show_bug.cgi?id=133845#c5 [8] https://bug-201242-attachments.webkit.org/attachment.cgi?id=377730 -- Frédéric Wang

2 4

PSA: Bit fields won't be packed on Windows if you mix types
by Ryosuke Niwa 04 Sep '20

04 Sep '20

Hi, Unlike gcc and clang, MSVC pads each consecutive member variables of the same type in bitfields. e.g. if you have: struct AB { unsigned m_1 : 31; bool m_2 : 1; } then *MSVC pads m_1 and allocates sizeof(unsigned) * 2 for AB* whereas gcc and clang only allocate sizeof(unsigned) * 1 for AB. This is *not a compiler bug*. It's a spec. compliant behavior, and may in fact have a better run-time performance in some situations. However, for core objects like RenderObject and InlineBox, allocating extra 4-8 bytes per each object is prohibitory expensive. In such cases, please *use the same POD type for all bitfield member variables*. (Storage class classifiers and variable qualifiers seem to have no effect on how variables are packed; e.g. mutable, const, etc...). For example, MSVC will allocate sizeof(unsigned) * 1 for AB if we rewrite the above code as: struct AB { unsigned m_1 : 31; unsigned m_2 : 1; } When you're making this change, *be sure to audit all code that assigns a non-boolean value to m_2* because implicit type coercion into boolean is no longer in effect. For example, AB ab; ab.m_2 = 2; puts(ab.m_2 ? "true" : "false"); will print "true" before the change and will print "false" after the change. An easy way to ensure you've audited all such code is to add getters and setters for all bitfield member variables or wrap them in a special structure or class as done in http://trac.webkit.org/changeset/103353 and http://trac.webkit.org/changeset/104254. Best regards, Ryosuke Niwa Software Engineer Google Inc.

4 8

Feedback on Blink's text fragment directive proposal
by David Bokan 31 Aug '20

31 Aug '20

Hello webkit-dev, I'd like to solicit feedback as well as an official position from Webkit on our proposal for the text fragment directive: https://github.com/WICG/ScrollToTextFragment. In summary: this is a feature that allows authors and users to craft URLs to pages and specify a snippet of text on the page as a subresource (visually highlighting it and scrolling it into view). Analogous to element-id based fragment anchors but for text. You can try this out today in Chrome Beta by enabling chrome://flags/#enable-text-fragment-anchor. Here's an example link: https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#:~:text=An%20opti… Relevant Links: <https://github.com/WICG/ScrollToTextFragment/blob/master/README.md> Explainer <https://github.com/WICG/ScrollToTextFragment/blob/master/README.md> Spec <https://wicg.github.io/ScrollToTextFragment/> TAG Review <https://github.com/w3ctag/design-reviews/issues/392> (Currently Suspended) Blink Intent Thread <https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/zlLSxQ9BA8Y/…> Issue on Mozilla standards-positions <https://github.com/mozilla/standards-positions/issues/194> We've been using the GitHub repo for issue tracking but happy to take feedback (official or otherwise) in any form. Thank you! David

4 4

Suggesting to enable paint timing by default
by Noam Rosenthal 20 Aug '20

20 Aug '20

Following the discussion with Simon in https://bugs.webkit.org/show_bug.cgi?id=78011 Since we have a pretty stable spec (https://w3c.github.io/paint-timing/) lots of passing web platform tests, other browser vendor support and a working implementation of first contentful paint, I am planning to submit a patch to enable paint timing by default. https://bugs.webkit.org/show_bug.cgi?id=211736 Any objections? Other thoughts?

4 13

Request for position on content-visibility
by Vladimir Levin 15 Aug '20

15 Aug '20

Hi, I'm asking for WebKit's position on CSS property content-visibility (spec draft: https://drafts.csswg.org/css-contain-2/#content-visibility) We're currently implementing this in Chromium and intend to ship it in the near future. Please let me know your thoughts, Vladimir Levin

2 1

EWS now parses error logs in case of build failure
by Aakash Jain 11 Aug '20

11 Aug '20

Hi Everyone, I am happy to announce another EWS feature. From now on, in case of build failure, EWS will parse the errors and display them in a separate 'errors' log. You wouldn't have to search through thousands of lines of logs to find the error message. For example, in https://ews-build.webkit.org/#/builders/16/builds/6054, in step #7 WebKit failed to compile. Complete logs (stdio) are 38,000+ lines, and the error is not at the end of the logs. Normally, it requires some searching through the logs to find the relevant errors. But now, there is another 'errors' log, which contains just the relevant 11 lines (containing error and few related lines to provide additional context). Hopefully this would save some time and efforts previously spent on searching through the large logs. Note that this information is not displayed in status-bubble tool-tip, since this might be lot of text to display in the tooltip. My further plan is to make this information more readily available, by adding it to a custom designed page which will open on clicking the status bubble https://webkit.org/b/197522 Please let me know if you notice any issues or have any feedback. Thanks Aakash Reference: https://webkit.org/b/203418

4 6