November 2020 - webkit-dev - lists.webkit.org

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

Request for position on Element Timing
by Nicolás Peña Moreno 27 Nov '20

27 Nov '20

Hi, I'd like to request WebKit's position on the Element Timing API, which lets web developers annotate images or text whose performance they care about. They can then obtain rendering timestamps from the PerformanceObserver. For cross-origin images the detailed information is gated on Timing-Allow-Origin. The proposed specification is at https://wicg.github.io/element-timing/ and is currently shipped in Chromium. Thanks!

2 5

Starting January 4, 2021, Google will block all sign-ins to Google accounts from embedded browser frameworks
by Michael Catanzaro 18 Nov '20

18 Nov '20

Hi, Today I received a Google Developers email with subject "[Action Required] Starting January 4, 2021, we will block all sign-ins to Google accounts from embedded browser frameworks." It linked to this Google blog post: https://developers.googleblog.com/2020/08/guidance-for-our-effort-to-block-… Summary: Google will attempt to block logins from "CEF-based apps and other non-supported browsers." Presumably "non-supported browsers" likely includes non-Safari WebKit, considering how much time I spend trying to develop user agent quirks to suppress Google's unsupported browser warnings on Gmail, Google Docs, etc. I guess we will find out on January 4. Google says: "The browser must identify itself clearly in the User-Agent. The browser must not try to impersonate another browser like Chrome or Firefox." We cannot comply with this because user agent spoofing is required for compatibility with various Google websites. I am continually fighting to maintain our user agent quirks for Google domains, see e.g. [1] or [2]. Even if we were to remove all user agent quirks, it would still be impossible for Google to distinguish between a desktop browser and an embedded browser framework, since the user agent header is going to be the same: Epiphany doesn't even append "Epiphany" anymore, in order to maximize the chances that websites will treat us like Safari. Even if we did, there are many other WebKit-based browsers that would be impacted (off the top of my head: eolie, surf, etc.) So we'll see what happens on January 4. If our users get locked out of google.com, I'll try to come up with new quirks if possible, but if Google is really determined to block non-Safari WebKit, it will win. E.g. it's easy to do JS feature detection (scary) or TLS handshake fingerprinting (extremely scary) and see we are not really the browser that our user agent quirk claims to be. We are largely toothless here, unfortunately. If Google continues to discriminate solely on the basis of the user agent header, and doesn't adopt any more advanced discrimination mechanisms, then we will survive, although it would help if Apple is willing to take a hard stance and adopt the same set of cross-platform quirks in Safari, which would "work" by causing Safari to break in the same way as non-Safari WebKit... probably not very palatable, but if adopted well in advance of this Jan 4 flag date, it would at least make it *harder* for Google to hurt non-Safari WebKit. (Adopting the quirks *after* the flag date would likely just immediately break Safari.) But if Google does this properly and uses more sophisticated browser fingerprinting techniques, Epiphany is done for. This could be an existential threat for non-Safari WebKit browsers. Nobody is going to be interested in using a browser that doesn't support Google websites. Google's expressly-stated goal is to block embedded browser frameworks and non-supported browsers from signing into Google accounts. The blog post says: "This block affects CEF-based apps and other non-supported browsers." It says: "We do not allow sign-in from browsers based on frameworks like CEF or Embedded Internet Explorer." Clearly CEF is the main target, but I guess WebKit (and likely also QtWebEngine) is at risk too; even if we're not mentioned directly, it seems pretty clear that WebKitGTK, WPE, PlayStation and WinCairo ports, etc. are all likely non-grata. So what should WebKit do about this? I don't know. Nothing has happened yet, so I guess we could wait and see what happens on January 4. Maybe this won't affect us at all. But my fear is that January 4 will arrive, we will be blocked, and more user agent quirks may or may not work. Even if WebKit is not blocked, we can be confident January 4 will be a sad day for browser diversity. I wonder if this is something that WebKit as a project could push back against... somehow. Maybe publish a statement supporting browsers based on embedded frameworks (WebKit, CEF, QtWebEngine)? Or some new WebKit project policy? Any suggestions? Michael [1] https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/platform/UserAg… [2] https://bugs.webkit.org/show_bug.cgi?id=215845

2 4

Reducing / removing use of Makefile based DerivedSources.make
by Sam Weinig 12 Nov '20

12 Nov '20

Hi webkit-dev, I’d like to propose, and gauge feedback on, reducing (with the goal of ultimately removing) the use of Makefile based DerivedSources.make. My understanding is that currently only the Xcode based ports still use DerivedSources.make, as all the CMake based ones have moved derived source generation to within CMake, so that should limit the scope of who this might affect. Why do we use Makefiles today? While I can’t recall the initial reasons for using Makefiles for derived sources, over the years there have been a number of advantages to it that I do know of. One clear advantage, that is no longer applicable, was code sharing, as earlier in the project, at least the Apple Windows port did utilize these Makefiles. Another was to work around some limitations in what dependencies Xcode was able to track with build rules. It seems at least some of the problems with build rules are no longer an issue, as we can now specify inputs to build rules, but I don’t if other problems will still be there, but for some prototyping I did, nothing yet has come up. What would we move to? As this only affects the Xcode based ports, we would move to distinct script phases and build rules in the Xcode project. Why make this change? What’s the benefit? There are few reasons to consider this. One advantage is simplifying the build system. Rather than two dependency systems (one for Xcode, one for the Makefile) we reduce it down to one. And with additional knowledge of the stages and dependencies, Xcode could potentially parallelize more phases. We would would also save some time by avoiding invoking make in the first place. We also have a bit of an issue with make itself, as due to system requirements, we are forever stuck with Make 3.81, which is coming up on being 15 years old. More than once in the last year I have tried to troubleshoot makefile issues, looking for resources on the web, only to be stymied because the solutions I found required newer make. What are the downsides? One potential downside will be that it will be a bit harder for those without Xcode to add new types of derived sources. I am not sure how much a real problem in practice this will be, as editing project.pbxproj files is already required for just adding new files, but I want to call it out anyway. What are your thoughts on this? Are there additional reasons we might want to stick with or move away from Makefile based derived sources? Thanks, -Sam

9 14

Reminder: include everything that you use in implementation files
by Brian Burg 12 Nov '20

12 Nov '20

Hello folks, I'd like to remind everyone to please include what you use in .cpp, .mm, and other files. When reviewing patches, please ensure that new mentions of classes, structs, etc. within an implementation file have a corresponding header include. All of our headers have #pragma once, so there is no downside to being more explicit. I've been noticing an uptick in the number of unified sources-related build failures. I can't remember the last nontrivial patch I wrote that did *not* include unrelated build fixes. Typically these failures aren't found until EWS results come back, reducing developer velocity. And obviosuly it's super annoying to encounter completely unrelated build failures that must be nonetheless addressed. Let's all do our part so that hacking on WebKit remains delightful. Thanks, Brian Burg (he/they)  WebKit Developer Experience

4 3

Position on WebXr Lighting Estimation Module
by Alex Cooper 12 Nov '20

12 Nov '20

Hello Webkit, I'd like to ask for WebKit's position on the WebXR Lighting Estimation Module. It's an extension of the WebXr Device API from the Immersive Web Community Group. The API allows web applications to request both the spherical harmonics representing ambient light as well as a reflection map. More details can be found in the explainer and specification draft. Explainer: https://github.com/immersive-web/lighting-estimation/blob/main/lighting-est… Spec Draft: https://immersive-web.github.io/lighting-estimation/ Chromestatus: https://www.chromestatus.com/features/5704707957850112 Could I get your position on this? Thanks, Alex Cooper

2 1

Request for position on Readable Byte Streams
by Nidhi Jaju 11 Nov '20

11 Nov '20

Hello Webkit-dev, I would like to ask for Webkit's official position on the readable byte streams API <https://streams.spec.whatwg.org/#readable-byte-stream> specification. For streams representing bytes, readable byte streams are an extended version of readable streams which are provided to handle bytes efficiently, and allow for BYOB (bring-your-own-buffer) readers to be acquired. TAG Review: https://github.com/w3ctag/design-reviews/issues/567 Chrome Platform Status Entry: https://chromestatus.com/feature/4535319661641728 Request for Mozilla Position: https://github.com/mozilla/standards-positions/issues/457 Thanks, Nidhi Jaju

1 0

Change to the lists.webkit.org From header field
by Ling Ho 11 Nov '20

11 Nov '20

To counter the recent increase in bounced mails due to DMARC enforcement by many receipient domains, we have made a configuration change. This is to prevent bounces which are causing list users from being unsubcribed from the webkit-dev and other WebKit mailing lists. The "From" header field will now shows "Full Name via webki-dev <webkit-dev(a)lists.webkit.org>". The "Reply to" field will show the correct sender and therefore Reply, Reply To and Reply List functions in your email clients should work correctly. Please let me know if you see any issue. Thanks, ... ling

1 0

Re: [webkit-dev] Embedding Identifiers in Commit Messages
by Jonathan Bedard 11 Nov '20

11 Nov '20

> > We appreciate everyone’s feedback on transitioning away from Subversion to Git, I’ll be releasing an expected timeline of up-coming changes in the next week before the contributors meeting. > > > > In the mean time, we’re preparing on adding identifiers to new commit messages, that work is tracked in https://bugs.webkit.org/show_bug.cgi?id=218407. <https://bugs.webkit.org/show_bug.cgi?id=218407.> At the moment, we’re likely going to be appending the identifiers to commit messages (as the current change proposes), but I wanted to provide a chance for folks to object to this change before it becomes canonical. > I'm a bit confused here. It looks like the patch only affects commits > made via webkit-patch. Given there are a lot of people who don't use > webkit-patch land, I'm not certain this strategy is sound even in the > short term. Furthermore, the proposed patch seems to have a race > condition when multiple commits are made concurrency? Why don't we do > this in post commit hook instead? > - R. Niwa We don’t have post commit hooks in SVN to do this sort of thing, and I don’t intend to add them now. We are going to have a system on GitHub to do this (not post commit hooks, but I won’t dive into the details here). There really aren’t a lot of people who land changes outside of webkit-patch, among things that would break if folks were regularly not using webkit-patch is trac.webkit.org <http://trac.webkit.org/>, which relies on the commit message being set. The types of changes that would fall outside of this change would be ones that don’t map well to a git world anyways, like the creation of a tag or branch. Notably, commit-queue is using this script. Lastly, this doesn’t add a race-condition that wasn’t already there. One of the downsides of SVN is that, unlike git, it is a centralized version control system, so clients must be synced to upstream before committing. This is true now, even if you haven’t noticed it. If we didn’t have this race condition, our changeling history would be full of weird conflicts. Jonathan

2 2

Missing mails since Nov 2, 2020.
by Ling Ho 11 Nov '20

11 Nov '20

Looks like there was a hiccup in the webkit-dev list this past week. I am sending this out to make sure every one can receive mails now. I don't know if it is possible to have them resent, so I'd like to encourage everyone to take a look at the list archive https://lists.webkit.org/pipermail/webkit-dev/2020-November/thread.html for any reply you were expecting, or new mails. Thanks, ... ling

1 0