February 2022 - webkit-dev - lists.webkit.org

mac-AS-debug-wk2 bot backed up
by Ken Russell 25 Feb '22

25 Feb '22

Hi WebKit developers, It looks like the mac-AS-debug-wk2 bot has an 18-hour backlog right now: https://ews-build.webkit.org/#/builders/60 while the mac-AS-debug bot is fine: https://ews-build.webkit.org/#/builders/61 Can more hardware be applied to mac-AS-debug-wk2? Thanks, -Ken -- I support flexible work schedules, and I’m sending this email now because it is within the hours I’m working today. Please do not feel obliged to reply straight away - I understand that you will reply during the hours you work, which may not match mine. (credit: jparent@)

2 3

Request for position: Cookie Expires/Max-Age attribute upper limit
by Ari Chivukula 23 Feb '22

23 Feb '22

I'd like to get WebKit's position on: (1) Having an explicit upper limit for Cookie Expires/Max-Age attributes (2) Having an explicit upper limit for Cookie Expires/Max-Age attributes that's less than or equal to 400 days https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#name-… https://github.com/httpwg/http-extensions/pull/1732 https://github.com/mozilla/standards-positions/issues/592 https://bugs.chromium.org/p/chromium/issues/detail?id=1264458 The draft of rfc6265bis now contains an upper limit for Cookie Expires/Max-Age attributes. As written: `The user agent MUST limit the maximum value of the [Max-Age/Expiration] attribute. The limit MUST NOT be greater than 400 days (34560000 seconds) in duration. The RECOMMENDED limit is 400 days in duration, but the user agent MAY adjust the limit to be less. [Max-Age/Expiration] attributes that are greater than the limit MUST be reduced to the limit.` 400 days was chosen as a round number close to 13 months in duration. 13 months was chosen to ensure that sites one visits roughly once a year (e.g., picking health insurance benefits) will continue to work. Safari is already partially compliant (has an upper age limit of 7 days when cookies are set client side), while Firefox and Chrome both support cookies with expiration dates orders of magnitude longer than a millenia in the future. According to measurements in Chrome of all cookies set about 20% have an Expires/Max-Age further than 400 days in the future. Of that 20%: half target 2 years, a quarter target 10 years or more, and the remainder are spread over the rest of the range. ~ Ari Chivukula (Their/There/They're)

3 3

Request for Position: Fetch Metadata
by Patrick Griffis 22 Feb '22

22 Feb '22

Hi everybody, I'd like a position on the Fetch Metadata[0] spec. It is a security feature that provides extra context to fetch requests so that servers can make informed decisions. It is currently implemented by both Firefox and Chromium. I have started a work-in-progress patch[1] on bug 204744 for this. It currently implements Sec-Fetch-Dest, Sec-Fetch-Mode, and part of Sec-Fetch-Site. However Sec-Fetch-User I believe will require more significant changes that will have to be exposed to each port. It requires knowing if a request was initiated by a user, exact details are specified here[2], which I think will require integration at the Safari/WebKitGTK/etc layers. So I'd appreciate input on if there is interest in this. Thanks, Patrick [0] https://www.w3.org/TR/fetch-metadata/ [1] https://bugs.webkit.org/show_bug.cgi?id=204744 [2] https://www.w3.org/TR/fetch-metadata/#directly-user-initiated

3 3

How to make changes to website?
by Michael Catanzaro 16 Feb '22

16 Feb '22

Hi, I want to make a modification to: https://webkit.org/contributing-code/ Suggested here: https://bugs.webkit.org/show_bug.cgi?id=232935#c6 It looks like this page is not part of WebKit/Websites/webkit.org. Anyone know who can edit it? Michael

2 2

Re: [webkit-dev] Great function for Cocoa platform, bridge_cast
by Darin Adler 16 Feb '22

16 Feb '22

Just economy. There is no need for two different names. I personally like it this way, and have found it appealing when I used it. I think you should give it a try. We can certainly change the name later if this turns out to significantly improve things. — Darin

2 2

Great function for Cocoa platform, bridge_cast
by Darin Adler 16 Feb '22

16 Feb '22

Hi folks. For those of you doing work with Objective-C on Cocoa platforms, I want to draw your attention to a great new idiom. Back in October, David Kilzer added bridge_cast, a type-safe set of functions that convert an Objective-C pointer to a Core Foundation pointer or vice versa, preserving types across the toll-free bridging boundary. It’s better than traditional non-WTF idioms where you use casts that look like “(__bridge id)” because you don’t have to write the type, and the correct corresponding type is chosen for you. When you have a CFStringRef and need to use it as an NSString key and value in an Objective-C dictionary, for example, the idiom would be: bridge_cast(constantKey): bridge_cast(constantValue), Rather than the old: (__bridge id)constantKey: (__bridge id)constantValue, It converts to NSString *, not id, which is better for many contexts, and good here, too. Since the function works in both directions, it will also turn an NSDictionary into a CFDictionaryRef. And it works on both raw pointers and on RetainPtr. I find it’s even more welcome to have something that can convert a RetainPtr<CFDictionaryRef> into RetainPtr<NSDictionary> without danger of getting the reference counting wrong, doing the right thing in both ARC and non-ARC source files, and optimizing the move cases appropriately. Please consider this instead of writing things like (CFStringRef)keyNS.get() because it’s easier to see it’s correct. — Darin

2 2

Request for position: prerendering
by Kouhei Ueno 11 Feb '22

11 Feb '22

Hi webkit-dev, This is a request for WebKit’s position on prerendering, which Safari already ships. Chrome would like to ship the feature too, and would like to do so in an interoperable way. We opened an issue at https://github.com/whatwg/html/issues/7533 , and have a draft spec at https://github.com/WICG/nav-speculation. We’d appreciate your thoughts on this. Thanks, Kouhei Ueno

1 0

Proposed changes to Bugzilla 'Resolution' categories
by Brent Fulgham 10 Feb '22

10 Feb '22

Hi Floks, I would like to propose some changes to the categories we use to resolve bugs. I’ve been trying to do some Bugzilla gardening to better reflect the state of various “edge case” bugs that often leave users confused about the state of issues they’ve reported, and unsure of whether fixes are needed or have been shipped. Some of this is due to inertia, but some is due to lack of clarity in how to treat a few categories of bugs. (1) Add a new “Behaves As Designed” option: This will represent bugs that were filed when the reporter misunderstands a feature, or wants behavior that we have considered, but chosen not to allow. This would be used instead of the somewhat offensive “WONTFIX” or mildly offensive “INVALID” resolutions we currently use. (2) Add a new “Platform To Resolve” option: This will represent bugs that are actually in an underlying component outside of sources in the WebKit project. This might be used to represent graphics driver bugs, kernel issues, platform User Interface libraries, or most frequently bugs in applications driving WebKit. This would be used instead of the somewhat offensive ‘INVALID” resolution. I’d like to hear thoughts on this idea, and whether people have improved labels or additional ideas in this space. I’m hoping to improve the clarity of the information in Bugzilla, as well as have a more respectful tone to people that take the time to file bugs with us. Thanks, -Brent

6 5

Tim Nguyen is now a WebKit reviewer
by Dean Jackson 09 Feb '22

09 Feb '22

Hi floks, Tim Nguyen is now a WebKit reviewer! Congratulations Tim! Dean

1 0

OK to flatten WTF's header directory?
by Elliott Williams 04 Feb '22

04 Feb '22

Hi webkit-dev, I’m working on fixing some ambiguities in our Xcode projects to permit adoption of Xcode’s new build system and better parallelize our builds. I noticed that WTF’s headers (/usr/lib/include/wtf) are atypical in that they aren’t copied into a single directory – they’re deeply nested and mirror the same directory hierarchy as exists in WTF’s sources. Is this intentional, and if not, would there be opposition to me flattening them into a single directory? Flattening them makes it easier to explain to Xcode what headers go where, which is useful for tracking dependencies between targets and ensuring proper build order. Headers would still be in their same source locations (alongside implementation files) but would be copied to the top-level /usr/lib/include/wtf directory at build time. The only other place in our projects [1] I’m aware of with deeply-nested headers is PAL, and there’s a bug to change that: https://bugs.webkit.org/show_bug.cgi?id=175705 <https://bugs.webkit.org/show_bug.cgi?id=175705> -Elliott [1]: libwebrtc also produces deeply-nested headers, but since it’s a third-party project, I don’t think our header conventions should apply.

5 7