[webkit-dev] WPT import status

[Sam Sneddon via webkit-dev]

https://github.com/WebKit/WebKit/pull/21912 hopefully serves as good progress 
here: this PR is almost largely done by automated tooling.

The first commit is the result of `import-w3c-tests` (the long standing 
command), but with no further work (to the expectations or baselines).

It then ran through EWS with the `no-failure-limits` label, before I added a 
second commit: the output of `update-test-expectations github-pr`, albeit 
limited to only changes it made to the relevant (dom) directory. This is where 
all the baselines come from in the PR.

This a roughly a workflow that’s useable in some cases today.

The most obvious limitation is that it only deals with baseline files 
(*-expected.txt), and not TestExpectations files (which means for things where 
the result is stored there—including reftest failures, debug differences, 
timeouts and crashes—it doesn’t work). Of the limitations this causes, reftests 
are by far the more apparent and mean this doesn’t work for most CSS tests yet.

The other obvious limitation is that it doesn’t deal with flaky tests, as shown 
by the PR failing after the second commit.

The final limitation, hinted at above, is that this doesn’t take any 
consideration of the current results on main—so it rebaselines far too much, 
depending on how well gardened main is when the PR run.

That said, the first and last of these are very much things we care about 
fixing, and we’ll see how problematic the second requiring manual intervention 
is.

I’d encourage people importing directories which have few reftests to try using 
the scripts mentioned above, and file any bugs they find.

What would be super helpful, to avoid making “turn on automated import” too 
painful, is updating directories we have imported that haven’t been updated 
recently.

And finally, as an aside, the `import-expectations.json` file now explicitly 
skips every top level directory we don’t import: I’d encourage you to take a 
look at what’s marked as skip, and if there’s more you think we should be 
importing (especially because we have implemented the spec in question!), I’d 
encourage you to do so by running `import-w3c-tests` with that directory, which 
will also change the relevant line in `import-expectations.json` from “skip” to 
“import”.

Happy New Year, (Web)Kittens,

Sam

PS: Apparently I messed up and my original draft with many more links to bugs 
didn’t get saved to a server-side draft mailbox, and I’m now on vacation, so 
please accept this much less-useful-than-intended email on current WPT import 
work! (I’ll try to reply with all the links once I get home in the New Year, 
although I will remain on leave for a while beyond.)___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position: Local Font Access

[Sam Sneddon via webkit-dev]

On 7 Apr 2022, at 23:34, Joshua Bell via webkit-dev 
 wrote:
> 
> This is a request for WebKit's position on introducing an API that allows 
> sites to request access to local font data, for use with content authoring 
> tools that use custom text stacks. 
> 
> Links:
> * Explainer: https://github.com/WICG/local-font-access/
> * Spec: https://wicg.github.io/local-font-access/
> * ChromeStatus: https://chromestatus.com/feature/6234451761692672

I’ll let others respond with regards to the font-data side, but from the font 
selection point of view:

The status quo for the Cocoa ports (macOS, iOS, etc.) is that only 
default-system fonts can be accessed from web content, and we’re concerned 
about undoing that change (it’s well documented that fonts have frequently been 
used as fingerprinting vectors). It is highly likely that any JS enumeration of 
fonts would be similarly limited to avoid increasing fingerprinting surface, if 
we were to implement such an API.

I believe we mentioned previously that we were strongly in favour of not 
allowing JS to enumerate fonts in any way, and would prefer to go in the path 
of a UA provided font selector.

This is touched on in the explainer: 
https://github.com/WICG/local-font-access#add-a-browseros-provided-font-chooser

> The proposed API exposes some more bits about the user via the web that could 
> improve fingerprinting efforts. The bits are based on the presence or lack of 
> presence of certain fonts in the enumeration-returned list.
> 
> An alternative to the API that only exposes a single user-selected font was 
> considered. This alternative enumeration API would trigger a 
> browser/OS-provided font chooser and, from that chooser, the user would 
> select a single font. This would reduce the bits exposed to help mitigate 
> fingerprinting at the cost of significant new functionality.
> 
> We've heard interest from partners in a full-fledged enumeration API to get 
> access to the list of available fonts on the system, and haven't heard 
> interest in a font-chooser approach to the enumeration API. However, we're 
> keeping the alternative in mind as we balance the need for new functionality 
> with privacy concerns.

We would be interested in hearing what your (Google’s? Chromium’s? Chrome’s?) 
partners have in way of use-cases that can only be fulfilled with the ability 
to enumerate fonts in JS, rather than have the UA mediate access to the 
fingerprinting-sensitive list.

/Sam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposed changes to Bugzilla 'Resolution' categories

[Sam Sneddon via webkit-dev]

Note we do have documentation of what they mean at 
https://webkit.org/bug-life-cycle/ , though 
this already appears to be incomplete (e.g., we have "CONFIGURATION CHANGED”, 
which I don’t know how people are meant to know what that means… what 
configuration?).

/Sam

> On 10 Feb 2022, at 20:11, Tim Nguyen via webkit-dev 
>  wrote:
> 
> Hi!
> 
> Pretty sure WORKSFORME corresponds to “Behaves As Designed”, that’s how 
> Mozilla’s bugzilla’s instance uses it at least.
> 
> Adding new resolution statuses seems fine, but maybe old ones (WORKSFORME, 
> WONTFIX, INVALID, etc.) should be cleaned up/migrated too, otherwise folks 
> (coming from other OSS projects using Bugzilla) will still keep using them. 
> Maybe they could be disabled.
> 
> -Tim
> 
>> On 10 Feb 2022, at 20:55, Brent Fulgham via webkit-dev 
>> mailto:webkit-dev@lists.webkit.org>> wrote:
>> 
>> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Fuzzy Reftest Plans, and Metadata Locations

[Sam Sneddon via webkit-dev]

Hi!

As part of the ongoing work on GPU Process, we’re interested in adding support 
for reftest fuzzy matching (i.e., allowing a certain amount of tolerance when 
comparing the generated images).

Our intention is to match the semantics of WPT’s reftests 
(https://web-platform-tests.org/writing-tests/reftests.html#fuzzy-matching):

There are cases where we’ll want to apply these to the tests unconditionally, 
for example where varying behaviour is expected across ports (such as 
anti-aliasing differences), and in these cases for WPT tests these annotations 
should probably be exported upstream.

The current plan, and work is underway to do this, is to support this syntax 
via parsing the HTML in Python when there is a hash mismatch, which should 
minimise the performance impact versus always reading this metadata.

However, this doesn’t entirely suffice. There are cases where we might want to 
allow more tolerance on one platform or another, or vary based on GPU model or 
driver. As such, this requires not only platform specific metadata (i.e., 
similar to that which we have in TestExpectations files today), but also 
expectations with finer granularity.

As such I think there are a few options here:

One option is to extend the meta content to encode conditional variants, though 
this doesn’t work for WPT tests (unless we get buy-in to upstream these 
annotations into the upstream repo, though that might be desirable for the sake 
of results on wpt.fyi). We would need to be confident that this wouldn’t become 
unwieldy however; we wouldn’t want to end up with something like 
(if:port=Apple)maxDifference=1;totalPixels=10,(if:platform=iOS)maxDifference=10;totalPixels=20,(if:port=GTK)maxDifference=10;totalPixels=300.

Another option is to extend TestExpectations to store more specific data 
(though again this might become unwieldy, as we’re unlikely to add new 
“platforms” based on every variable we might want to distinguish results on). 
This also means the metadata is far away from the test itself, and the 
TestExpectations files would continue to grow even further (and we already have 
34k lines of TestExpectations data!). TestExpectations is also a rather 
horrible file format to modify the parser of.

There is also test-options.json which has most of the same downsides as 
TestExpectations, albeit without the pain in modifying the parser.

Finally, we could add per-test or per-directory files alongside the tests. (Due 
to how things work, these could presumably also be in directories in 
platform/.) This I think is probably the best option as it keeps the metadata 
near the test, without needing to modify the test (which, per above, is 
problematic for WPT as we move to automatically exporting changes). One could 
imagine either a __dir__-metadata.json (to use a similar name to how WPT names 
directory-level metadata files) or a -expected-fuzzy.json file alongside each 
test.

Your opinions would be warmly welcomed!

Thanks,

Sam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] JPEG XL support?

[Sam Sneddon via webkit-dev]

> I don't have any strong opinion on JPEG XL, asides from the general 
> observation that adding more image decoders written in memory-unsafe 
> languages is a generally sad thing to do. (I'm still not happy about how we 
> were forced to support JPEG 2000 a couple years back due to websites using 
> Akamai Image Manager.) In particular, I notice that libjxl is quite a lot of 
> C++ code. On the other hand, given that WebKit is itself all C++, you could 
> reasonably say something about "people in glass houses should not throw 
> stones." :) So even though image decoders are quite sensitive, that shouldn't 
> be a blocker IMO.
> 
> The most important point you need to know is that Safari doesn't use WebKit's 
> image decoders at all, so if you want JPEG XL to work in Safari, contributing 
> JPEG XL support to WebKit is not likely going to achieve your goal. Even if 
> Safari did use our image decoders, which it doesn't, we don't copy 
> third-party projects into the WebKit source without a *very* exceptional 
> reason to do so (as for ANGLE or libwebrtc), so OS support for JPEG XL is 
> going to be key. There are two cases:
> 
> (1) Non-Apple platforms use image decoders under 
> Source/WebCore/platform/image-decoders. Depending on libjxl if it is 
> installed as a system library, and using it to implement a JPEG XL image 
> decoder under Source/WebCore/platform/images-decoders/jpegxl, seems OK to me. 
> (Whereas copying libjxl into the WebKit source repo would certainly not be 
> OK. That's way too much code.) There would need to be a CMake build option to 
> disable the dependency for systems where libjxl is not available as a system 
> library. It would only make sense to do this if somebody makes an effort to 
> package libjxl for at least a few major Linux distros, otherwise it won't be 
> used in practice. PlayStation and Windows ports can then build libjxl 
> themselves if they so choose.
> 
> (2) Apple platforms use CoreGraphics for image decoding, see 
> Source/WebCore/platform/graphics/cg/ImageDecoderCG.[cpp,h]. I don't know much 
> about this, but I don't think it's open source, so I would guess that 
> contributions are probably not possible. I'm not sure what to tell you here. 
> Hopefully somebody from Apple will comment.

This is pretty much accurate as far as the Apple port is concerned; image 
format support depends on OS library support, rather than anything in WebKit. 
And indeed, the relevant OS libraries aren’t open source. And to be clear, 
Apple’s OSes do not currently support JPEG XL.

/Sam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position: ES modules for Service Workers

[Sam Sneddon via webkit-dev]

> On 11 Mar 2021, at 23:37, Ghazale Hosseinabadi via webkit-dev 
>  wrote:
> 
> Hi webkit-dev,
> 
> This is a request for WebKit's position on ES modules for Service Workers. 
> Explainer:
> https://github.com/w3c/ServiceWorker/commit/6d9500e99e764c12b117c63d10107e094d243662
>  
> 
> Spec:
> https://w3c.github.io/ServiceWorker 
> 
>  (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. 

Given WebKit has implemented it 
(https://trac.webkit.org/changeset/273224/webkit/ 
), and it is in STP 122, I 
think it is a safe assumption that WebKit is supportive of it. 

/Sam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position: CSS custom counter style

[Sam Sneddon via webkit-dev]

> On 19 Feb 2021, at 20:39, Xiaocheng Hu via webkit-dev 
>  wrote:
> 
> Hi webkit-dev,
> 
> This is a request for WebKit's position on CSS custom counter style 
> (@counter-style rule). The spec status is Candidate Recommendation. Firefox 
> has shipped it in 2014, while Chrome is planning to ship it by M90 in April 
> 2021.
> 
> Explainer: https://developer.mozilla.org/en-US/docs/Web/CSS/@counter-style 
> 
> Spec: https://drafts.csswg.org/css-counter-styles-3 
> 
> 
> Summary: The CSS @counter-style rule allows web authors to specify and use 
> custom counter styles in list markers and CSS counters. This helps web 
> internationalization.
> 
> Thanks!

We are generally supportive of it.

/Sam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev