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

Can we remove ENABLE_STREAMS_API compile flag?
by Tetsuharu OHZEKI 29 Jun '20

29 Jun '20

Hi WebKitten, As I see the following codes and grep, I seem today's all (?) ports of WebKit have enabled ENABLE_STREAMS_API flag by default. - https://trac.webkit.org/browser/trunk/Source/WTF/wtf/PlatformEnable.h?rev=2… - https://trac.webkit.org/browser/trunk/Source/cmake/OptionsFTW.cmake?rev=263… - https://trac.webkit.org/browser/trunk/Source/cmake/OptionsWin.cmake?rev=263… - https://trac.webkit.org/browser/trunk/Source/cmake/OptionsMac.cmake?rev=263… - https://trac.webkit.org/browser/trunk/Source/cmake/WebKitFeatures.cmake?rev… - https://trac.webkit.org/browser/trunk/Source/cmake/tools/vsprops/FeatureDef… If my assumption is right, I'd like to propose to remove this `ENABLE_STREAMS_API` flag. What do you think about this? If I missed some ports, please tell me about them. -- Tetsuharu OHZEKI tetsuharu.ohzeki(a)gmail.com

2 2

Switching open source Debug bots to building and testing with configuration --force-opt=O3
by Mark Lam 24 Jun '20

24 Jun '20

Hi folks, We're planning to switch the JSC EWS bot and build.webkit.org <http://build.webkit.org/> Debug build and test bots to building with the following set first: ./Tools/Scripts/set-webkit-configuration --force-opt=O3 This means the Debug builds will be built with optimization level forced to O3. Why are we doing this? 1. So that the JSC EWS will start catching ASSERT failures. 2. JSC stress test Debug bots have been timing out and not running tests at all. Hopefully, this change will fix this issue. 3. Tests will run to completion faster and we’ll catch regressions sooner. The downside: crash stack traces will be like Release build stack traces. But I don’t think we should let this deter us. It’s not like there’s no stack information. And just as we do with debugging Release build test failures, we can always do a Debug build locally to do our debugging. We would like to apply this change to all Debug build and test bots, not just the JSC ones. Does anyone strongly object to this change? Thanks. Cheers, Mark

8 26

@webkitbot in slack is available
by Yusuke Suzuki 22 Jun '20

22 Jun '20

Hi all, Some of you already noticed (and used it), webkitbot is available in WebKit slack's #dev channel. We can use it like the following as you know in IRC days. @webkitbot revert 260220 Crash several JSTests Then, webkitbot opens bugzilla issue and uploads revert patch for you. In early development phase, Simon heavily used and reported a lot of bugs and improvements. Those are fixed and integrated well into slack @webkitbot and it is working well. Thanks so much! -Yusuke ===== The implementation is uploaded in https://bugs.webkit.org/show_bug.cgi?id=211707

1 0

Request for position on Media Feeds
by Becca Hughes 18 Jun '20

18 Jun '20

Hi webkit-dev, I would like to request an official position on Media Feeds. Explainer: https://github.com/WICG/media-feeds/blob/master/explainer.md Chrome Status: https://chromestatus.com/feature/5695114963845120 TAG review: https://github.com/w3ctag/design-reviews/issues/477 Thanks, Becca

2 2

Intent to remove FileError
by Tetsuharu OHZEKI 12 Jun '20

12 Jun '20

Hi WebKitten, I'm not sure that we have a kind of this process, but I think this mail might be helpful for some developers relying on this legacy interface. ## Summary I removed `FileError` as a web-exposed interface. By this change, `FileReader.error` uses `DOMException` instead. ## Explanation AFAIK, `FileError` was used in the earlier spec about 10 years ago. https://www.w3.org/TR/2010/WD-FileAPI-20101026/ And it had been changed to `DOMError` but it was also replaced to `DOMException` in 2017. https://github.com/w3c/FileAPI/issues/11 Other browsers followed this spec change several years ago, but WebKit is still exposing this interface. * Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1120178 * Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=460725 Thus I removed FileError as a web-exposed interface in bug 213117. https://bugs.webkit.org/show_bug.cgi?id=213117 I plan to remove internal usages for FileError.{h,cpp} in bug 213119. https://bugs.webkit.org/show_bug.cgi?id=213119 -- Tetsuharu OHZEKI tetsuharu.ohzeki(a)gmail.com

1 0

Request for position on removing 'no-preference' for prefers-color-scheme media feature
by Rune Lillesveen 09 Jun '20

09 Jun '20

Hi, Per CSSWG resolution [1], 'no-preference' has been removed from the Media Queries Level 5 specification. We (Blink) intend to align with the spec and remove support for the 'no-preference' keyword from Blink. Firefox has also stated that they will follow to do so [2]. [1] https://github.com/w3c/csswg-drafts/issues/3857#issuecomment-634779976 [2] https://groups.google.com/a/chromium.org/d/msg/blink-dev/3RhZFvZE1LM/t7BpLB…

2 1

Fwd: Position on emerging standard: Scroll-linked Animations
by Majid Valipour 08 Jun '20

08 Jun '20

Hi, I like to request an official WebKit/Safari position on the Scroll-linked Animations proposal. The proposal has been in incubation in CSSWG (and in WICG before that) for some time now and has received feedback from WebKit engineers among other working group participants. Links to additional relevant documents and discussions: - Explainer: https://github.com/w3c/csswg-drafts/blob/master/scroll-animations-1/EXPLAIN… - Draft Specification: https://drafts.csswg.org/scroll-animations/ - Some key open issues: https://github.com/w3c/csswg-drafts/milestone/6 - Request for Mozilla's Position: https://github.com/mozilla/standards-positions/issues/347 - Blink Intent to Implement: https://groups.google.com/a/chromium.org/d/msg/blink-dev/8V4ixKVmNY4/vJQdo9… Thanks, Majid Valipour

2 2

Re: [webkit-dev] Request for position on First-Party Sets
by Maciej Stachowiak 04 Jun '20

04 Jun '20

> On Jun 3, 2020, at 5:21 PM, Kaustubha Govind <kaustubhag(a)chromium.org> wrote: > > Hi Maciej, > > Thanks for feedback. > > We had previously started the incubation process in WICG, and it was just moved there: https://github.com/WICG/first-party-sets <https://github.com/WICG/first-party-sets> > > In addition, I have also filed a Proposal Issue in PrivacyCG: https://github.com/privacycg/proposals/issues/17 <https://github.com/privacycg/proposals/issues/17> Thanks! I expressed support for the above proposal. > > Regarding your concern about preventing (a) Bad faith claims, and (b) The “500 domains” problem. These are absolutely cases that we would consider "unacceptable sets", and our initial thinking was that this would be covered by the "UA Policy" and be subject to review during the acceptance/verification process. In this version of the proposal, we attempted to build maximum flexibility for UAs; but it has since become clear that browsers find this problem worth solving, and also deem it important to agree on a common policy. We are currently working on an initial draft of a policy, and will bring that for discussion when ready. That sounds like a positive development, looking forward to it. > > Kaustubha > > > > > > On Wed, May 27, 2020 at 3:16 PM Maciej Stachowiak <mjs(a)apple.com <mailto:mjs@apple.com>> wrote: > > (1) I notice that this proposal still exists only in a random personal repo. Could it please be contributed to an appropriate standards or incubation group? Privacy CG would almost certainly welcome this, and I’m sure it would be easy to move to WICG as well. There doesn’t seem to be a reason to keep the proposal in this “pre-incubation” state. > > (2) As discussed in the Privacy CG Face-to-Face, there are two key problems to solve with First Party Sets or any similar proposals: > (a) Bad faith claims. How to prevent domains that are not actually owned and controlled by the same party from making claims of being related? For example, an ad network could get its top publishers to enter an association to regain a certain level of tracking powers. > (b) The “500 domains” problem. If a first party owns domains that aren’t obviously related and that appear to different and distinct brands to the user, then the user won’t expect to be tracked across them. (Problem named such because of a party known to have hundreds of domains that mostly appear to be totally distinct brands). Users would expect both transparency and control over this. > > The explainer does not really give solutions to these problems. Rather, it defers entirely to each individual browser to define a policy to solve these problems. Deferring to individual browsers on such key points is problematic in a few ways: > (i) It doesn’t seem right for a proposed web standard to solve only the easy problem of syntax, and leave the hardest technical problems of semantics to each browser separately. > (ii) Deferring in this way is bad for interop. > (iii) It’s not entirely clear if there exists any policy that suitably addresses these problems. By only speculating about policies, the explainer fails to provide an existence proof that it is implementable. > (iv) If sites come to depend on First Party Sets for correct behavior, there is a risk that every UA will have to adopt a policy that’s the most permissive of any, or that copies the most popular UA, for the sake of compatibility. Thus, leaving this open may not in fact provide a useful degree of freedom. > > Given these issues, I don’t think we’d implement the proposal in its current state. That said, we’re very interested in this area, and indeed, John Wilander proposed a form of this idea before Mike West’s later re-proposal. If these issues were addressed in a satisfactory way, I think we’d be very interested. It does seem that binding strictly to eTLD+1 is not good enough for web privacy features. Driving these issues to resolution is part of why we’d like to see this proposal adopted into a suitable standards or incubation group. > > Regards, > Maciej > > >> On May 27, 2020, at 9:33 AM, Lily Chen <chlily(a)chromium.org <mailto:chlily@chromium.org>> wrote: >> >> 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 <https://github.com/krgovind/first-party-sets> >> [2] Previous feedback: https://github.com/krgovind/first-party-sets/issues/6 <https://github.com/krgovind/first-party-sets/issues/6> >> [3] TAG review: https://github.com/w3ctag/design-reviews/issues/342 <https://github.com/w3ctag/design-reviews/issues/342> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev(a)lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev> >

1 0