October 2021 - webkit-dev - lists.webkit.org

Request for position: CSS highlight inheritance (css-pseudo #highlight-cascade)
by Delan Azabani 28 Oct '21

28 Oct '21

I’m seeking WebKit’s position on the “Cascading and Per-Element Highlight Styles” section of css-pseudo-4 [0]. Most impls (with the sole exception of Presto) have historically not propagated highlight styles through the element tree. This has meant that only the global ::selection selector (*::selection) worked intuitively, and made it awkward to style the highlights on some subset of elements. Authors had to repeat each selector with a “*” descendant, and ensure that “overriding” rules win the cascade. For example, to highlight content under p.foo in yellow, but content under <em> anywhere in the document in cyan, one might: p.foo::selection, p.foo *::selection { background-color: yellow; } em:not(#specificity)::selection, em:not(#specificity) *::selection { background-color: cyan; } The spec gives highlights an inheritance-based processing model, where all properties (inherited or otherwise) default to the value on the parent’s highlight. Note that the spec’s processing model is no longer cascade-based, as of w3c/csswg-drafts#2474 [1]. We believe the compat risk is minimal, because the new model won’t break existing content with global ::selection rules, nor will it break rules that use the cascade to build an ersatz “propagation” like the example above. As far as we can tell, only content that relies on descendants of a highlight-styled element being reset to initial styles should be affected. [0] https://drafts.csswg.org/css-pseudo-4/#highlight-cascade [1] https://github.com/w3c/csswg-drafts/issues/2474 Cheers, Delan Azabani Igalia // web platform

1 1

New fast commit queue mode: fast-cq
by Aakash Jain 25 Oct '21

25 Oct '21

Hi Everyone, I am happy to inform you that I have added a fast-commit-queue mode to the Commit-Queue. In this mode Commit-Queue would land patches quickly (typically taking ~1 minute, e.g.: https://ews-build.webkit.org/#/builders/28/builds/10876) This mode skips building and testing. It basically does sanity check (like validating ChangeLog, Reviewer, Committer etc.) and commits the patch. This is intended to be used for scenarios where the patch is a build fix, urgent fix, quick typo/follow-up fix etc. To use this mode, you can use the --fast-cq parameter while uploading the patch using webkit-patch command. e.g.: 'webkit-patch upload --fast-cq'. For patches which are already uploaded to Bugzilla, you can rename the patch (by clicking on 'Details' button for the patch), and prefix patch name with [fast-cq], e.g.: '[fast-cq] Patch for landing'. Pro-tip: you can also rename the patch to include [fast-cq] prefix while marking the patch cq+, from patch 'Details' page, and this mode would work. Please let me know if you have any questions/feedback. Thanks Aakash

2 4

Proposal to change nested namespace indentation rule to match the existing code
by Kimmo Kinnunen 22 Oct '21

22 Oct '21

Hello, I’d like to propose changing the WebKit coding standard regarding indentation of nested namespace contents. The change would be to not add indentation for nested namespace contents. This would be to: 1) Match what seems to already be de-facto used in code. 2) Subjectively simplify the rules. For me personally "never indent” is simple to understand. 3) Subjectively no downsides. For me personally indenting contents of nested namespaces does not seem to gain readability and does not seem to reduce bugs. 4) Subjectively side-step the issue of what the style guide means. I don’t personally understand what "and any nested namespaces with the same scope” means. The change: https://bugs.webkit.org/show_bug.cgi?id=232073 <https://bugs.webkit.org/show_bug.cgi?id=232073> Current guide: https://webkit.org/code-style-guidelines/#indentation <https://webkit.org/code-style-guidelines/#indentation> Please comment if you feel strongly about this. Now: namespace WebCore { namespace Nested { struct NestedPayload { }; } struct WebCorePayload { }; } After: namespace WebCore { namespace Nested { struct NestedPayload { }; } struct WebCorePayload { }; } Br, Kimmo

3 2

Recommended GitHub Settings
by Jonathan Bedard 21 Oct '21

21 Oct '21

Hey folks, We’ve had some contributors reach out to us about notifications they are starting to receive because of our development of GitHub pull-requests. Given the size of the WebKit project, we have a few recommendations of how to configure your notification settings. On https://github.com/WebKit/WebKit <https://github.com/WebKit/WebKit>, under the “Watch” menu, you can pick when you are notified. By default, this is “All Activity,” which will include every pull-request anyone makes. It’s unlikely this is desirable. You most likely want to only be notified on pull-requests you are specifically mentioned in or are participating in, if you want to be notified at all. In addition to this, I will start inviting active contributors to the WebKit organization based on the GitHub usernames in contributors.json. You should be able to accept this invite at https://github.com/WebKit <https://github.com/WebKit> when it comes. Jonathan WebKit Continuous Integration

1 0

Proposal to enable logging under non-systemd linux distros
by Pablo Correa Gomez 21 Oct '21

21 Oct '21

Dear webkit maintainers, I am a contributor to postmarketos/alpine linux. We recently bumped into some runtime crashes in webkit2gtk which were very hard to debug due to the lack of logging. The reason for the lack of logging seems to be that alpine configures webkit2gtk with -DPORT=GTK -DUSE_SYSTEMD=OFF and then the USE_JOURNALD macro does not get set. However, in systems like alpine which do not use systemd, it is common that a compatible logind, elogind[1], be used. When this is the case, then the current functions used for logging to systemd's journal are perfectly compatible. To make sure it works, I have create a small patch/hack to test it, which compiled in a system with elogind instead of systemd USE_SYSTEMD=ON: diff -ru a/Source/cmake/FindSystemd.cmake b/Source/cmake/FindSystemd.cmake --- a/Source/cmake/FindSystemd.cmake +++ b/Source/cmake/FindSystemd.cmake @@ -68,6 +68,11 @@ HINTS ${PC_SYSTEMD_LIBDIR} ${PC_SYSTEMD_LIBRARY_DIRS} ) +find_library(Systemd_LIBRARY + NAMES ${Systemd_NAMES} elogind + HINTS ${PC_SYSTEMD_LIBDIR} ${PC_SYSTEMD_LIBRARY_DIRS} +) + include(FindPackageHandleStandardArgs) find_package_handle_standard_args(Systemd FOUND_VAR Systemd_FOUND I would be happy to contribute a decent patch, but as it would modify the parameters available for distros to configure, I have some doubts about which would be the best way to proceed. I could see two options: - Create a new configuration option (USE_ELOGIND), most likely muplicating most of systemd cmake code. - Rename USE_SYSTEMD to USE_JOURNALD and have a conditional check which looks for elogind if libsystemd is not found, similar to the hack I used for proof-testing. My question is, which of these two options would be best suitable? If none of them is, which would be the better way to add the possibility to configure webkit2gtk using elogind? Best regards and thank you very much for your time, Pablo Correa Gómez. [1] https://github.com/elogind/elogind

2 2

Status of video-dynamic-range media query
by Will Cassella 21 Oct '21

21 Oct '21

Hey everyone, I'm working on enabling the dynamic-range and video-dynamic-range media queries <https://www.w3.org/TR/mediaqueries-5/#dynamic-range> in Chromium (they're currently implemented though default-disabled behind a feature flag). I wrote a WPT <https://wpt.fyi/results/css/mediaqueries/dynamic-range.html> to test for support for these queries, and I noticed that while WebKit supports the 'dynamic-range' query, it doesn't support the 'video-dynamic-range' query. I was just wondering if there are any plans currently to add support for that query as well. Thanks, Will

1 0

EWS iOS, tvOS, watchOS are updated to the latest released SDK
by Matt Lewis 20 Oct '21

20 Oct '21

Hello WebKit Devs, iOS, watchOS, and tvOS bots on build.webkit.org and ews-build.webkit.org have been updated to the latest available Xcode and SDKs: iOS 15, watchOS 8, and tvOS 15. Happy Coding, Matt Lewis

1 0

Re: [webkit-dev] -Wreturn-type and -Wredundant-move reminders
by Ryosuke Niwa 19 Oct '21

19 Oct '21

On Tue, Oct 19, 2021 at 1:15 PM Michael Catanzaro via webkit-dev < webkit-dev(a)lists.webkit.org> wrote: > A reminder about this common idiom: > > switch (...) { > case Foo: > return ...; > case Bar: > return ...; > } > RELEASE_ASSERT_NOT_REACHED(); > > When it's intended that the code always returns inside the switch > statement, the RELEASE_ASSERT_NOT_REACHED() is required to avoid > tripping GCC's -Wreturn-type. If you forget it, I or somebody else will > wind up adding it later to avoid the warning. Clang does not warn here, > and this is the most common type of warning I clean up, so please don't > forget! :) This warning is useful in other situations, and it seems > nicer to placate GCC than to disable it. > > I'll sneak in another reminder: "return WTFMove()" is almost always not > needed. Clang warns only if the move prevents return value > optimization, but GCC will always warn if it detects the move is > unneeded. > Can we add a style checker rule to detect at least simple cases? - R. Niwa

2 1

Updating iOS EWS
by Matt Lewis 19 Oct '21

19 Oct '21

We are currently updating all embedded EWS hosts to iOS15 aligned releases. Expect delays and offline hosts. We appreciate your patience. Matt Lewis

1 0

Request for position: WEBRTC-SVC
by Harald Alvestrand 19 Oct '21

19 Oct '21

Chrome is considering releasing an implementation of the WEBRTC-SVC API. API documentation: https://w3c.github.io/webrtc-svc/ This has been available in Chrome behind a flag for some time, and we believe it is ready for wider availability. As part of the process of evaluating whether or not to release this, we would like to have input from the WebKit community. Thank you! Harald Alvestrand

2 1