Re: [webkit-dev] Deployment of new EWS Non-Unified builder
If it's useful as a data point, in Gecko we used not to care about non-unified builds. This worked kind of ok, because the file arrangements were mostly deterministic by directory. However, folks running with weird build configurations always ended up hitting these issues (and they might not know that they're not their fault). Furthermore, various IDEs and tooling rely on dependencies being right / files building in non-unified mode to provide useful diagnostics while editing the files (e.g, we have a code review bot that runs clang-tidy on the files you touched, and if the dependencies are not right it just fails). To that end, we have a bot that builds a "hybrid" build configuration, and runs on CI. It's "hybrid" in the sense there's a per-directory opt out; there are some directories that still haven't been fixed to build without unified builds, but the goal is that eventually everything should build in non-unified builds. See [1] for the details. In my experience, the occasional fix-up for non-unified builds is better / simpler than having to untangle the mess after the fact (see [2] for a recent example). Cheers, -- Emilio [1]: https://firefox-source-docs.mozilla.org/build/buildsystem/unified-builds.html#building-outside-of-the-unified-environment [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1772513 On 5/21/22 06:17, dpino via webkit-dev wrote: Hi, Last year we started a thread to discuss the possibility of deploying a new EWS bot that builds WebKit with Non-Unified sources [1]. This thread explains the technical reasons why a non-unified build bot is desirable. If you're aware of the problems introduced by unified sources compilation, skip the next paragraph. Unified sources compilation consists of merging several source files together into one big file to improve building times. Usually the same sources files are grouped together, but compilation flags or downstream changes can create different source file groups. When that happens, you may hit a build error. Since unified sources group files together, missing headers in one file can be satisfied by another file in the same group. What's happening in WebKit development currently is that source code that breaks non-unified compilation frequently lands without even being noticed. The breaks are usually related to missing headers. Embedders that need to support WebKit builds with different flags or maintain downstream changes are more likely to hit these compilation errors. Last year's attempt to deploy an EWS Non-Unified builder ended up in a deployment of a post-commit bot plus two workers running in the UAT. It was actually hard to get the Non-Unified builder working [2], something that we achieved at the beginning of this year (kudos to Adrián and Lauro). Since then we have been maintaining the post-commit bot very closely. There are periods of time where the bot has remained green for a long period of time. But lately maintaining the bot green has become harder and harder, specially due to the big refactorizations that have happened in WebKit source code lately. The bot very rarely stays green longer than 2 or 3 days without close maintenance. We believe that we all should share the responsibility of keeping the non-unified build working, and therefore we want to proceed with the deployment of a EWS Non-Unified builder. Initially, we'll provide two workers on a modern host with 8 cores assigned each. We have found this setup faster for most patches than many of the existing EWS queues, as it only runs a build in non-unified mode, without test or upload steps. If this were not fast enough, we would consider increasing the number of workers in the queue. We set up a page[3] with a rough comparison to the regular (unified) bot and the build times are pretty similar. Diego [1] https://www.mail-archive.com/webkit-dev@lists.webkit.org/msg30077.html [2] https://bugs.webkit.org/show_bug.cgi?id=226088 [3] https://people.igalia.com/lmoura/webkit-bots-dashboard/unified.html ___ 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
Re: [webkit-dev] Request for position: CSS scrollbar-gutter
I guess that'd solve parts of the issue, but not the use-case of non-overlay scrollbars in overflow: auto causing reflow when the content initially overflows. But it seems like a much simpler version of scrollbar-gutter (one that would only work with non-overlay scrollbars, and on scrollable boxes) could solve. -- Emilio On 2/23/21 22:08, Emilio Cobos Álvarez via webkit-dev wrote: Just thinking out loud, but has an environment variable for scrollbar widths (maybe two, one for thin scrollbars, one for regular-width scrollbars) be enough to do the job here? I recall similar proposals in the CSSWG, but I'm not sure if they were discussed seriously. It seems it should be easier to implement, off-hand, and maybe less confusing? And it would allow the pattern Simon mentions here. It should also allow solving some of the issues people hit with vh/vw if non-overlay scrollbars are used[1]. I guess for that last use-case we'd really need two pairs of values, one of which should return zero for overlay scrollbars for that use-case to work...? Anyhow, seems like this could be discussed in the CSSWG. -- Emilio [1]: https://github.com/w3c/csswg-drafts/issues/6026 On 2/23/21 18:45, Simon Fraser via webkit-dev wrote: WebKit does not support this feature as specified. Our opinion is that we don't want to encourage web developers to reserve space for scrollbars in a way that prevents non-interactive content from intruding into that space. This undoes a big advantage of overlay scrollbars, in that they leave more space for content. Our preference would be some kind of margin value (perhaps a constant) that allows authors to move only interactive content outside of the area affected by overlay scrollbars. Simon On Feb 23, 2021, at 5:54 AM, Felipe Erias via webkit-dev wrote: Hi webkit-dev, This is a request for WebKit's position on the CSS "scrollbar-gutter" property. The spec status is Working Draft. This feature is already implemented in Chrome behind a flag. Spec: https://drafts.csswg.org/css-overflow-4/#scrollbar-gutter-property Explainer: https://github.com/felipeerias/scrollbar-gutter-explainer Existing WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=167335 Summary: The scrollbar-gutter property provides control over the presence of scrollbar gutters (the space which may be reserved to display a scrollbar). This gives Web authors more agency over how their layouts interact with the scrollbars provided by the browser, so they can e.g. prevent excessive layout changes as content expands while avoiding unwanted visuals when scrolling isn't needed. Thanks! Best. Felipe ___ 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 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
Re: [webkit-dev] Request for position: CSS scrollbar-gutter
Just thinking out loud, but has an environment variable for scrollbar widths (maybe two, one for thin scrollbars, one for regular-width scrollbars) be enough to do the job here? I recall similar proposals in the CSSWG, but I'm not sure if they were discussed seriously. It seems it should be easier to implement, off-hand, and maybe less confusing? And it would allow the pattern Simon mentions here. It should also allow solving some of the issues people hit with vh/vw if non-overlay scrollbars are used[1]. I guess for that last use-case we'd really need two pairs of values, one of which should return zero for overlay scrollbars for that use-case to work...? Anyhow, seems like this could be discussed in the CSSWG. -- Emilio [1]: https://github.com/w3c/csswg-drafts/issues/6026 On 2/23/21 18:45, Simon Fraser via webkit-dev wrote: WebKit does not support this feature as specified. Our opinion is that we don't want to encourage web developers to reserve space for scrollbars in a way that prevents non-interactive content from intruding into that space. This undoes a big advantage of overlay scrollbars, in that they leave more space for content. Our preference would be some kind of margin value (perhaps a constant) that allows authors to move only interactive content outside of the area affected by overlay scrollbars. Simon On Feb 23, 2021, at 5:54 AM, Felipe Erias via webkit-dev wrote: Hi webkit-dev, This is a request for WebKit's position on the CSS "scrollbar-gutter" property. The spec status is Working Draft. This feature is already implemented in Chrome behind a flag. Spec: https://drafts.csswg.org/css-overflow-4/#scrollbar-gutter-property Explainer: https://github.com/felipeerias/scrollbar-gutter-explainer Existing WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=167335 Summary: The scrollbar-gutter property provides control over the presence of scrollbar gutters (the space which may be reserved to display a scrollbar). This gives Web authors more agency over how their layouts interact with the scrollbars provided by the browser, so they can e.g. prevent excessive layout changes as content expands while avoiding unwanted visuals when scrolling isn't needed. Thanks! Best. Felipe ___ 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 mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
