July 2020 - webkit-dev - lists.webkit.org

Plugin process
by Michael Catanzaro 20 Aug '20

20 Aug '20

Hi, Is anybody still using the plugin process? I understand that Safari does not allow plugins anymore. Epiphany doesn't either, nor does anything packaged in Linux distros (afaik). If nothing is using it, maybe we can delete a lot of code? Is it exposed in Apple system APIs? WebKitGTK still has an enable-plugins setting that is not yet deprecated. Probably long past time to at least deprecate it. There's also, incredibly, an enable-java setting, which I presume toggles the old Java browser plugin. I sense there must be some history behind that setting. :)

5 7

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

Request for Webkit position for Imperative Shadow DOM Distribution API
by Yu Han 06 Aug '20

06 Aug '20

Hi Webkit-Dev, We would like to get an official position from webkit for Imperative Shadow DOM Distribution API. This proposal was discussed in the last TPAC F2F <https://github.com/whatwg/html/issues/3534#issuecomment-537802687>. And Chrome has implemented this API based on the F2F summary. - Specification Title: Imperative Shadow DOM Distribution API - Explainer <https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Imperative-Sha…> - Spec PRs for HTML <https://github.com/whatwg/html/pull/5483> and DOM <https://github.com/whatwg/dom/pull/860> - WhatWG DOM issue discussion <https://github.com/whatwg/html/issues/3534>. - TAG Review <https://github.com/w3ctag/design-reviews/issues/486>. - ChromeStatus <https://chromestatus.com/feature/5711021289242624> - Caniuse.com URL (optional): - Bugzilla URL (optional): - Mozillians who can provide input (optional): Other information The imperative Shadow DOM distribution API allows developers to explicitly set the assigned nodes for a slot element. With this API, web developers can create web components without needing to add a specific markup, slot="" attribute, to children of the host component. In addition, it enables conditional slotting based on either environmental state or an attribute passed in. More details, including more motivating uses cases, can be found in the explainer <https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Imperative-Sha…> . Example syntax: <custom-tab show-tab="2"> <tab-panel></tab-panel> <tab-panel></tab-panel> <tab-panel></tab-panel></custom-tab> class CustomTab extends HTMLElement { static get observedAttributes() { return ['show-tab']; } constructor() { super(); const shadowRoot = this.attachShadow({mode: 'open', slotAssignment: 'manual'}); shadowRoot.innerHTML = ` <div class="custom-tab"> <slot></slot> </div>`; } attributeChangedCallback(name, oldValue, newValue) { UpdateDisplayTab(this, newValue); } connectedCallback() { if (!this._observed) { const target = this; const showTab = this.getAttribute('show-tab'); const observer = new MutationObserver(function(mutations) { UpdateDisplayTab(target, showTab); }); observer.observe(this, {childList: true}); this._observed = true; } }} function UpdateDisplayTab(elem, tabIdx) { const shadow = elem.shadowRoot; const slot = shadow.querySelector("slot"); const panels = elem.querySelectorAll('tab-panel'); if (panels.length && tabIdx && tabIdx <= panels.length ) { slot.assign([panels[tabIdx-1]]); } else { slot.assign([]); }} thanks, Han

2 3

Request for position on MediaRecorder constant bitrate audio encoding
by Simon Jackson 04 Aug '20

04 Aug '20

Hello WebKit-dev, I'd like to ask for Webkit's official position on a change to the editors draft of the mediacapture-record specification to make it possible to request either constant or variable bitrate audio encoding from the MediaRecorder. - Specification: https://w3c.github.io/mediacapture-record/#mediarecorder-api - Pull request & discussion of additions: w3c/mediacapture-record#185 <https://github.com/w3c/mediacapture-record/pull/185> - Explainer: https://docs.google.com/document/d/10OheBob6lP7v-fO89g0A5F9BYnsMEU5Nkh4p-Bk… - Chromestatus entry: https://chromestatus.com/feature/5730124735447040 A new enumeration (BitrateMode) has been added for specifying either constant or variable bitrate for audio encoding, MediaRecorderOptions has an extra field called audioBitrateMode for requesting a specific bitrate mode from the MediaRecorder and a field was added to MediaRecorder for retrieving the bitrate mode being used for encoding. Thanks, Simon

2 2

Request for position on "Make system colors compute to themselves"
by Kevin Babbitt 29 Jul '20

29 Jul '20

Hi webkit-dev, I'm working on implementing the change described in CSSWG issue 3847 "Make system color keywords compute to themselves" in Blink and wanted to request a position statement from WebKit on this behavioral change. Discussion: https://github.com/w3c/csswg-drafts/issues/3847 Spec: https://drafts.csswg.org/css-color-4/#resolving-color-values chromestatus.com entry: https://www.chromestatus.com/feature/5728029949034496 This is newly specified behavior for an existing web platform feature. Presently, the computed value of a CSS system color keyword can be the rgb value that the keyword maps to. However, this causes problems when a color keyword is inherited across elements with differing values for the color-scheme property. For example, suppose we have an element with "color-scheme: light; color: MenuText". At computed-value time, the MenuText keyword will be mapped to an rgb value using the light color scheme. If that element has a child with "color-scheme: dark" and no specified value for "color", it will inherit the *rgb value*, which will not match the desired dark color-scheme on the child. Instead, the parent element's computed value for color should be MenuText. The child will inherit the *keyword*, and at resolved-value time, the keyword is mapped to the rgb value using the dark color scheme. Please let me know your thoughts and thanks for your consideration, Kevin

1 0

Request for position on Azimuth/Altitude for Pointer Events
by Liviu Tinta 28 Jul '20

28 Jul '20

Hello WebKit-dev, I'd like to ask for Webkit's official position on adding Azimuth/Altitude to Pointer Events as described in [1]. The proposal was discussed by the Pointer Events Working Group and Pointer Events specification was updated [2]. The discussion and specification update happened in [3], [4], [5], [6], [7], [8], [9]. Mozilla standards-position: https://github.com/mozilla/standards-positions/issues/411 TAG Review: https://github.com/w3ctag/design-reviews/issues/537 [1] Explainer: https://docs.google.com/document/d/1BkJDlHJvR6jndtJys7IYuqwITgVi6P9iOnfA0z5… [2] Pointer Events : https://w3c.github.io/pointerevents/#dom-pointerevent-altitudeangle [3] PE Issue 321: https://github.com/w3c/pointerevents/issues/321 [4] PE Issue 320: https://github.com/w3c/pointerevents/issues/320 [5] PE Issue 274: https://github.com/w3c/pointerevents/issues/274 [6] PE PR 316: https://github.com/w3c/pointerevents/pull/316 [7] PE PR 322: https://github.com/w3c/pointerevents/pull/322 [8] PE PR 323: https://github.com/w3c/pointerevents/pull/323 [9] PEWG minutes: https://www.w3.org/2020/05/27-pointerevents-minutes.html Thank you, Liviu Tinta

2 1

Generating compile_commands.json when building WebKit on MacOS
by shrivatsa＠firemail.cc 27 Jul '20

27 Jul '20

Hi webkit-dev, I'm trying to study the structure of web browsers in general and WebKit specifically for academic purposes. I found that using language servers that index compile_commands.json (clangd, ccls etc.) is a very good solution to navigate source code of extremely large projects, such as WebKit. Unfortunately, I was only able to get compile_commands.json generated when I compiled with --jsc-only where the build is executed using cmake and not the perl script. Trying to pass --cmake as a build argument to build-webkit causes the build to fail pretty early for missing files (that I believe aren't open source). To wrap it up, I wonder if there's a way to compile WebKit as a browser (and not just JavaScriptCore) and have compile_commands.json generated? platform: osx arch: x86_64 commit: 521d40b Thanks,

6 8

Re: [webkit-dev] [webkit-changes] [264332] trunk/Source
by Darin Adler 17 Jul '20

17 Jul '20

We need to be cautious about adding header includes to other headers. Adding includes to .cpp files is likely fine and not a deeply consequential decision, but adding to headers is something that can have a massive effect on build times over time. > On Jul 13, 2020, at 10:44 PM, Hironori.Fujii(a)sony.com wrote: > <>Modified: trunk/Source/WebCore/platform/graphics/ColorSerialization.h (264331 => 264332) > > --- trunk/Source/WebCore/platform/graphics/ColorSerialization.h 2020-07-14 05:17:20 UTC (rev 264331) > +++ trunk/Source/WebCore/platform/graphics/ColorSerialization.h 2020-07-14 05:44:25 UTC (rev 264332) > @@ -25,6 +25,8 @@ > > #pragma once > > +#include <wtf/text/WTFString.h> This change is wrong. The header to include here is Forward.h, not WTFString.h. Not super-harmful since WTFString.h is already so widely included, but we need to be really cautious in headers. > Modified: trunk/Source/WebCore/svg/SVGParserUtilities.h (264331 => 264332) > > --- trunk/Source/WebCore/svg/SVGParserUtilities.h 2020-07-14 05:17:20 UTC (rev 264331) > +++ trunk/Source/WebCore/svg/SVGParserUtilities.h 2020-07-14 05:44:25 UTC (rev 264332) > @@ -24,6 +24,7 @@ > #include "ParsingUtilities.h" > #include <wtf/HashSet.h> > #include <wtf/Vector.h> > +#include <wtf/text/WTFString.h> Same mistake. I’d really like to come up with some other system for reviewing adding headers to *headers*. — Darin

11 18

New EWS queues for tvOS and watchOS
by Aakash Jain 14 Jul '20

14 Jul '20

Hi Everyone, I am happy to announce that we have added new EWS queues for tvOS and watchOS. From now on, you would see four new status bubbles (on Bugzilla bug) named: tv, tv-sim, watch, watch-sim (corresponding to device and simulator builds for watchOS and tvOS). This should help in preventing any accidental build breakage on these platforms. Please let me know if you notice any issue. Thanks Aakash

3 3