June 2022 - webkit-dev - lists.webkit.org

Jean-Yves is now a WebKit reviewer
by Dean Jackson 16 Jun '22

16 Jun '22

🎉🎈🥳 Jean-Yves Avenard is now a WebKit reviewer. May the “merge-queue” label serve you well, Jean-Yves! Dean

1 0

Request for Position: Deprecating Non-ASCII characters in cookie domain attributes
by Johann Hofmann 16 Jun '22

16 Jun '22

Hi folks, This is a heads up that I'm planning to deprecate non-ASCII characters in cookie domain attributes in Chromium, meaning that these cookies will be rejected going forward. See https://groups.google.com/a/chromium.org/g/blink-dev/c/x3DY-PuZhNw for all details. This is following a discussion in the HTTP WG <https://github.com/httpwg/http-extensions/issues/1707> and subsequent specification <https://github.com/httpwg/http-extensions/pull/1969> in RFC 6265bis. While John Wilander from Apple was part of the discussion, I'd still like to extend the request to this list to give feedback on the proposal. >From my understanding, for Safari, this is handled in the OS network stack instead of WebKit, and I believe the internal bug on your side to be rdar://88349235 As both Chromium and Safari currently accept these cookies, there is a potential for breakage. However, in Chrome, usage appears to be low enough to move forward with deprecation and removal, see the linked thread above. Thanks! Johann

1 0

Request for position: DisplayMediaStreamConstraints.surfaceSwitching
by Elad Alon 16 Jun '22

16 Jun '22

This is a request for WebKit's position on extending getDisplayMedia to also accept DisplayMediaStreamConstraints.surfaceSwitching. The PR that introduced this behavior to the getDisplayMedia spec was approved by Apple engineer Youenn Fablet. Links: * Explainer: https://docs.google.com/document/d/1kqdLoUcwWe8znVCMXyz2FHk9WMylHbIo7gUjhyH… * Spec: https://github.com/w3c/mediacapture-screen-share/pull/225/files * ChromeStatus entry: https://chromestatus.com/feature/5067650299330560

1 0

Request for position: WebAssembly Relaxed SIMD
by Deepti Gandluri 15 Jun '22

15 Jun '22

Hi webkit-dev, The WebAssembly Relaxed SIMD proposal introduces new vector operations that take advantage of widely available instruction sets to accelerate compute workloads. The proposal relaxes the strict portability constraints of the fixed-width SIMD proposal <https://github.com/WebAssembly/simd/tree/master/proposals/simd>. We're hoping to ship this in Chrome 105/106 contingent on a Phase 4 <https://github.com/WebAssembly/proposals#phase-4---standardize-the-feature-…> (currently at Phase 3) vote in the Wasm CG, requesting a WebKit position for the proposal. Proposal: https://github.com/WebAssembly/relaxed-simd Spec: https://github.com/WebAssembly/relaxed-simd/tree/main/document/core Implementation status (V8, SpiderMonkey): https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-sim… Preliminary performance data that motivated the proposal: https://github.com/WebAssembly/simd/pull/79 Thanks, Deepti

1 0

Request for position on Custom Highlight API
by Daniel Clark 15 Jun '22

15 Jun '22

Hi webkit-dev, I would like to request WebKit's current position on the CSS Custom Highlight API [1]. Edge and Chrome are planning to ship this soon [2]. Safari implemented an early version of this API in 99 [3], gated behind the Highlight API experimental flag. It looks like it's been updated since then to match changes in the spec, e.g. HighlightRangeGroup has been renamed to Highlight. The remaining major difference between the Safari and Chromium implementation is that the Safari implementation doesn't yet support live Ranges, only StaticRanges. The API is still off-by-default, behind the experimental flag. Is there anything that can be shared about WebKit's plans to further develop the API and eventually ship it on-by-default? Thanks, Dan Clark [1] https://drafts.csswg.org/css-highlight-api-1/ [2] https://groups.google.com/a/chromium.org/g/blink-dev/c/pxgVrAzMfyk [3] https://developer.apple.com/safari/technology-preview/release-notes/#r99

1 0

Xcode workspace builds enabled by default in build-webkit; expect faster build times
by Elliott Williams 14 Jun '22

14 Jun '22

Hi folks, As part of ongoing work to adopt Xcode’s modern build system, I have turned on “workspace builds” by default for build-webkit as of <https://commits.webkit.org/251501@main>. When building for Mac, iOS, watchOS, or tvOS (including builds made by EWS bots), expect build times to drop, sometimes by a lot! In this new build workflow, build-webkit makes a single xcodebuild invocation and builds the “All Modules” scheme, instead of recursing through the WebKit tree one project one at a time [1]. This scheme builds all WebKit targets in parallel, in any dependency order Xcode chooses. Increased parallelism, plus lower overhead between projects results in marginally faster full builds and significantly faster incremental builds [2]. One caveat to this build workflow is that we need to emit enough metadata to Xcode’s build system for it to infer the dependency relationships between targets. This is automatic for targets that link against another—for example, Xcode sees that WebCore links against JavaScriptCore and ensures they build in proper order—but often requires manual intervention when there is a headers-only dependency between targets. Please let me know if you’re seeing build failures where a target is building before one of its included headers is available, and refer to <https://commits.webkit.org/246026@main> for the way we typically register dependencies between otherwise unrelated build products. You can access the old sequential-based build workflow by passing `--no-use-workspace.` At this time, `make` still builds sequentially, but I intend to change `make USE_WORKSPACE=YES` to be the default soon. Elliott [1]: This is exactly what opening WebKit.xcworkspace and building from the Xcode IDE does, and while we don’t have much test coverage of that workflow, I expect that by making build-webkit behave much more like and IDE build, we are fixing inconsistencies and odd behaviors in both places. [2]: It’s hard to make an accurate statement on the impact of workspace builds for EWS and build queues, because of some separate bug fixes I’m landing to avoid unnecessary full builds on bots <https://bugs.webkit.org/show_bug.cgi?id=241586>. However, I’ve been testing workspace builds on a post-commit bot for a few months now, and compared with a similar-spec builder, workspace builds yield a 10x improvement in minimum build time and a 20x improvement (!) in median time: Apple-BigSur-XCBuild-Release-Build min 28s median 100s max 5552s Apple-Monterey-Release-Build min 254s median 2382s max 5768s

1 0

Request for Position: Auto-sizes for lazy-loaded images in HTML
by Simon Pieters 14 Jun '22

14 Jun '22

Hi, I'd like WebKit's position on the proposal: Add sizes=auto to lazy-loaded <img> This allows web developers to omit the `sizes` attribute, or explicitly specify `sizes=auto`, for <img> elements that have `loading=lazy`. The browser will use the layout width of the image as input to the srcset resource selection (lazy images don't start loading until layout is known, at the earliest). For eager-loading images, it's invalid and equivalent to `100vw`. Spec issue: https://github.com/whatwg/html/issues/4654 Spec PR: https://github.com/whatwg/html/pull/8008 Chromium position: https://github.com/whatwg/html/issues/4654#issuecomment-1154412434 Mozilla standards position: https://github.com/mozilla/standards-positions/issues/650 cheers, -- Simon Pieters Bocoup https://bocoup.com/

1 0

Proposal: Mandatory Commit and Merge Queue
by Jonathan Bedard 06 Jun '22

06 Jun '22

As we move to GitHub, I would like to propose we strengthen our protections on `main` by making MergeQueue and CommitQueue mandatory. This would mean that with a few exceptions, all changes would need to be built and run layout tests before they are landed. To spell out what the exceptions I had in mind are: - Revert commits, identified by a commit message that starts with “Unreviewed, revering…” would be exempt - Changes which only modify files that do not effect building or testing WebKit would be exempt. These files specifically are: .github/ JSTests/ ManualTests/ metadata/ PerformanceTests/ Tools/ CISuport/ EWSTools/ WebKitBot Websites/ - Emergency build and infrastructure fixes, identified by a commit message that starts with “Emergency build fix” or “Emergency infrastructure fix” would be exempt - A reviewer who is not the commit author can overwrite this protection by adding `unsafe-merge-queue` instead of the commit author - Changes which passed an EWS layout test queue within the last 7 days would skip the layout test check These exceptions are designed to provide contributors for a way to by-pass potentially slow checks if extraordinary situations, or in ones where CI has already validated the change. I think we should keep the ability for any committer to deploy an emergency fix, because our project has many contributors in different timezones and with different holiday schedules. We know that this policy change would potentially slow down development, so I think these 3 improvements block making MergeQueue and CommitQueue mandatory: - run-webkit-tests consulting results.webkit.org <http://results.webkit.org/> to avoid retrying known flakey or failing tests - Another MergeQueue bot - Xcode workspace builds to speed up incremental builds Jonathan Bedard WebKit Continuous Integration

4 8

Request for position on import.meta.resolve()
by Domenic Denicola 06 Jun '22

06 Jun '22

Hi webkit-dev, We're proposing a small additional function to add to the HTML Standard, named import.meta.resolve(). See the PR [1] and a mini-explainer [2]. Gecko folks have reviewed the PR and contributed to the discussion, but any thoughts from WebKit would be very welcome. We're hoping to ship in Chrome within the next few weeks, and I imagine web developers would love it if you were to also implement. We have a basic implementation and web platform tests you may find useful [3]. Thanks, Domenic [1]: https://github.com/whatwg/html/pull/5572 [2]: https://gist.github.com/domenic/f2a0a9cb62d499bcc4d12aebd1c255ab [3]: https://chromium-review.googlesource.com/c/chromium/src/+/3456729

1 0

Add CODEOWNERS to WebKit
by Jonathan Bedard 06 Jun '22

06 Jun '22

Hey folks, Yusuke is interested in adding the CODEOWNERS file to the WebKit project (see https://github.com/WebKit/WebKit/pull/1137 <https://github.com/WebKit/WebKit/pull/1137>). There have been some objections to this, the two ones I’m aware of: - WebKit doesn’t assign “ownership” to pieces of code, so the name is unfortunate - The last match “wins”, so if you subscribed to a generic directory early in the file, more specific matches would override that subscription Despite these downsides, I think adding the CODEOWNERS file is good for the project for a few reasons: - It’s a standard natively supported by GitHub, BitBucket and GitLab and will be familiar to developers - File format is more simple than existing watchlist - Support for groups and individuals - No need for WebKit to host a service (other implementations of auto-CCing would require this) I intend to work with Yusuke to land https://github.com/WebKit/WebKit/pull/1137 <https://github.com/WebKit/WebKit/pull/1137> and start adopting CODEOWNERS on Monday absent objections that folks think overshadow the benefits of the CODEOWNERS file. Jonathan

3 4