Re: [webkit-dev] Deployment of new EWS Non-Unified builder

[Emilio Cobos Álvarez via webkit-dev]

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

[Emilio Cobos Álvarez via webkit-dev]

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

[Emilio Cobos Álvarez via webkit-dev]

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

Re: [webkit-dev] Smart Pointer Analysis Tool for WebKit

[Emilio Cobos Álvarez]

Interesting. This looks fairly similar to some of the checkers we use in 
mozilla-central, fwiw.


One interesting difference is that we opted for explicitly annotating 
the functions that can run script (think updateStyleIfNeeded(), 
dispatchEvent() etc equivalents) to be able to not warn for cases where 
using raw pointers is fine. See [1] for the current rules we're using.


So, I wonder... for a concrete example like [2], what is what would 
allow you to use shadowHost() without storing it on a local RefPtr 
otherwise, for example? Or is the plan to either pay the refcount churn, 
or silence the warnings on a per-case basis?


Cheers,

  -- Emilio

[1]: 
https://searchfox.org/mozilla-central/rev/f4b4008f5ee00f5afa3095f48c54f16828e4b22b/build/clang-plugin/CanRunScriptChecker.cpp#5-49
[2]: 
https://webkit-search.igalia.com/webkit/rev/4c54a6d287d7fba30e1fb37d5afda692fb12a758/Source/WebCore/dom/Node.cpp#1041


On 9/17/20 8:32 AM, Ryosuke Niwa wrote:

Hi all,

I’ve been working with Geoff (ggaren) and Jan Korous from Apple's 
compiler team to create a static analyzer which detects dangerous use of 
ref counted objects, and we’re looking for folks who are interested in 
trying out this tool and helping us refine the tool. Please let me know 
if you’re interested in using this tool & try applying code changes to 
WebKit. Our goal is to eventually integrate this tool into buildbot and 
EWS so that we can catch dangerous code before they get committed.


*What is Dangerous?*

So *what is* a /dangerous/ use of ref counted objects you may ask? It’s 
any use of which we can’t trivially conclude that it doesn’t lead to a 
use-after-free.


For now, we don’t detect dangerous use of non-ref counted objects 
including ones that can vend WeakPtr. It’s on us, humans, to decide 
which objects need to be ref counted or need to be CanMakeWeakPtr.


Consider the following example. This code most certainly will lead to a 
use-after-free of “parent” in the third line because the code doesn’t 
keep the parent alive. Because isContentEditable updates style in some 
cases, it could lead to arbitrary script execution which could remove 
the parent from the document.


Node* parent = element->parentElement();
if (parent->isContentEditable())
     parent->scrollIntoView();

In general, relying on a complex data structure such as DOM tree to keep 
RefCounted objects alive while we call a non-trivial function is not 
safe. All it takes for the code to have a use-after-free is for someone 
to start updating style, layout, etc… inside the function either 
directly or indirectly. And we don’t want to make WebKit development 
really hard by forcing anyone who modifies a function to check every 
caller of the function and their callers, etc… to make sure it’s safe to 
do so.


For this reason, it’s /dangerous/ to store a raw pointer or a reference 
to a ref counted object as a local variable and use it after calling a 
non-trivial function. We did a similar analysis of a number of other 
patterns and usage of ref counted objects in WebKit and came up with the 
following basic rules for using ref counted objects in a safe manner. 
We’re hoping that these rules would be eventually incorporated into our 
coding style guideline: https://webkit.org/code-style-guidelines/ 



*Rules for Using Ref Counted Objects*

 1. Every data member to a ref counted object must use either Ref,
RefPtr, or WeakPtr. webkit.NoUncountedMemberChecker


 2. Every ref counted base class, if it has a derived class, must define
a virtual destructor. webkit.RefCntblBaseVirtualDtor


 3. Every ref counted object passed to a non-trivial function as an
argument (including "this" pointer) should be stored as a Ref or
RefPtr in the caller’s local scope unless it's an argument to the
caller itself by transitive property [1].
alpha.webkit.UncountedCallArgsChecker


 4. Every ref counted object must be captured using Ref or RefPtr for
lambda. webkit.UncountedLambdaCapturesChecker


 5. Local variables - we’re still working on this
(https://reviews.llvm.org/D83259 )


Below, I've dissected each one of these rules with the real warning 
emitted by the analysis tool in development. Please let me know if you 
have any comments / concerns.



(1) is pretty trivial. Every ref counted data member should be stored 
using Ref, RefPtr, or WeakPtr since it would be not trivially obvious 
that life cycles of two or more objects are correctly tied or 

Re: [webkit-dev] [blink-dev] Re: What to do about scroll anchoring?

[Emilio Cobos Álvarez]

A quick status update here:

I landed some heuristics to disable scroll anchoring in pathological 
cases in Firefox a long while ago. This stopped virtually all compat 
issues, though it's obviously not great.


Chris and other Chromium folks have been doing work to fix Chromium 
issues that were causing these interop problems, and improving the 
scroll anchoring spec.


So I'm going to try and peek up those spec changes in Firefox and then 
try to remove those heuristics on Nightly, and see how it goes.


 -- Emilio

On 11/7/19 12:07 AM, Chris Harrelson wrote:

HI Emilio,

I'll follow up on crbug.com/920289 <http://crbug.com/920289>. Let's 
discuss there.


On Tue, Oct 29, 2019 at 3:03 PM Emilio Cobos Álvarez <mailto:emi...@mozilla.com>> wrote:


Hi all,

   10/18/19 7:19 PM, Chris Harrelson wrote:
 > Hi,
 >
 > Another quick update: Emilio, Navid, Nick, Stefan and I met today and
 > discussed which issues are important to fix and why. We now have
a list of
 > spec issues, and WPT tests to fix that are Chromium bugs, that should
 > substantially improve interop. Nick and Stefan will take on the
work to fix
 > them, with the review and feedback support of Emilio.

So, today another scroll-anchoring bug crossed my radar, and this one
I'm not sure at all how to fix it, because there's no obvious answer
here as far as I can tell.

My diagnosis (for one of the pages, the one I could repro and
reduce) is
in here[1], but basically my current explanation is that the page
should
be broken per spec, and that when it works it's hitting a bug in both
Chromium[2] which we have an equivalent of but are just not hitting
because in Firefox changing `overflow` does more/different layout work
than in Chrome.

The test-case may as well work if we change our scroll event or timer
scheduling (see there), but that is obviously pretty flaky.

I honestly don't have many better ideas for more fancy heursitics about
how to unbreak that kind of site. From the point of view of the
anchoring code, the page is just toggling height somewhere above the
anchor, which is the case where scroll anchoring _should_ work, usually.

I can, of course (and may as a short-term band-aid, not sure yet) add
`overflow` to the magic list of properties like `position` that
suppress
scroll anchoring everywhere in the scroller, but that'd be just kicking
the can down the road and waiting for the next difference in layout
performance optimizations between Blink and Gecko to hit us.

I think (about to go on PTO for the next of the week) I'll add
telemetry
for pages that have scroll event listeners, and see if disabling scroll
anchoring on a node when there are scroll event listeners attached
to it
is something reasonable (plus adding an explicit opt-in of course).

I'm not terribly hopeful that the percentage of such documents is going
to be terribly big, to be honest, but providing an opt-in and doing
outreach may be a reasonable alternative.

Another idea would be to restrict the number of consecutive scrolls
made
by scroll anchoring to a given number at most. That would made the
experience in such broken websites somewhat less annoying, but it'll
also show flickering until that happens, which would make the browser
still look broken :/.

Thoughts / ideas I may not have thought of/be aware of?

Thanks,

   -- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1592094#c15
<https://bugzilla.mozilla.org/show_bug.cgi?id=1592094#c15>
[2]: https://bugs.chromium.org/p/chromium/issues/detail?id=920289
<https://bugs.chromium.org/p/chromium/issues/detail?id=920289>

 > Thanks all,
 > Chris
 >
 >
 > On Thu, Oct 10, 2019 at 2:13 PM Rick Byers mailto:rby...@chromium.org>> wrote:
 >
 >> Sorry for the delay.
 >>
 >> We agree that scroll anchoring has unrealized potential to be
valuable for
 >> the web at large, and to make that happen we should be investing
a lot more
 >> working with y'all (and if we can't succeed, probably removing
it from
 >> chromium). Concretely +Chris Harrelson who leads rendering for
Chrome (and
 >> likely someone else from his team), as well as +Nick Burris from
the Chrome
 >> input team will start digging in ASAP. In addition to just the
normal
 >> high-bandwidth engineer-to-engineer collaboration between
chromium and
 >> gecko I propose the following high-level goals for our work:
 >>
 >>     - Ensure that there are no known deviations in behavior between
 >>     chromium and the spec (one way or the other).
 >>     - Ensure all the (non-ua-specific) site c

Re: [webkit-dev] [blink-dev] Re: What to do about scroll anchoring?

[Emilio Cobos Álvarez]

Hi all,

 10/18/19 7:19 PM, Chris Harrelson wrote:

Hi,

Another quick update: Emilio, Navid, Nick, Stefan and I met today and
discussed which issues are important to fix and why. We now have a list of
spec issues, and WPT tests to fix that are Chromium bugs, that should
substantially improve interop. Nick and Stefan will take on the work to fix
them, with the review and feedback support of Emilio.


So, today another scroll-anchoring bug crossed my radar, and this one 
I'm not sure at all how to fix it, because there's no obvious answer 
here as far as I can tell.


My diagnosis (for one of the pages, the one I could repro and reduce) is 
in here[1], but basically my current explanation is that the page should 
be broken per spec, and that when it works it's hitting a bug in both 
Chromium[2] which we have an equivalent of but are just not hitting 
because in Firefox changing `overflow` does more/different layout work 
than in Chrome.


The test-case may as well work if we change our scroll event or timer 
scheduling (see there), but that is obviously pretty flaky.


I honestly don't have many better ideas for more fancy heursitics about 
how to unbreak that kind of site. From the point of view of the 
anchoring code, the page is just toggling height somewhere above the 
anchor, which is the case where scroll anchoring _should_ work, usually.


I can, of course (and may as a short-term band-aid, not sure yet) add 
`overflow` to the magic list of properties like `position` that suppress 
scroll anchoring everywhere in the scroller, but that'd be just kicking 
the can down the road and waiting for the next difference in layout 
performance optimizations between Blink and Gecko to hit us.


I think (about to go on PTO for the next of the week) I'll add telemetry 
for pages that have scroll event listeners, and see if disabling scroll 
anchoring on a node when there are scroll event listeners attached to it 
is something reasonable (plus adding an explicit opt-in of course).


I'm not terribly hopeful that the percentage of such documents is going 
to be terribly big, to be honest, but providing an opt-in and doing 
outreach may be a reasonable alternative.


Another idea would be to restrict the number of consecutive scrolls made 
by scroll anchoring to a given number at most. That would made the 
experience in such broken websites somewhat less annoying, but it'll 
also show flickering until that happens, which would make the browser 
still look broken :/.


Thoughts / ideas I may not have thought of/be aware of?

Thanks,

 -- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1592094#c15
[2]: https://bugs.chromium.org/p/chromium/issues/detail?id=920289


Thanks all,
Chris


On Thu, Oct 10, 2019 at 2:13 PM Rick Byers  wrote:


Sorry for the delay.

We agree that scroll anchoring has unrealized potential to be valuable for
the web at large, and to make that happen we should be investing a lot more
working with y'all (and if we can't succeed, probably removing it from
chromium). Concretely +Chris Harrelson who leads rendering for Chrome (and
likely someone else from his team), as well as +Nick Burris from the Chrome
input team will start digging in ASAP. In addition to just the normal
high-bandwidth engineer-to-engineer collaboration between chromium and
gecko I propose the following high-level goals for our work:

- Ensure that there are no known deviations in behavior between
chromium and the spec (one way or the other).
- Ensure all the (non-ua-specific) site compat constraints folks are
hitting are captured in web-platform-tests. I.e. if Gecko passes the tests
and serves a chromium UA string it should work as well as in Chrome (modulo
other unrelated UA compat issues of course).
- Look for any reasonable opportunity to help deal with UA-specific
compat issues (i.e. those that show up on sites that are explicitly looking
for a Gecko UA string or other engine-specific feature). This may include
making changes in the spec / chromium implementation. This is probably the
toughest one, but I'm optimistic that if we nail the first two, we can find
some reasonable tradeoff for the hard parts that are left here. Philip (our
overall interop lead) has volunteered to help out here as well.

Does that sound about right? Any suggestions on the best forum for tight
engineering collaboration? GitHub good enough, or maybe get on an IRC /
slack channel together somewhere?

Rick

On Mon, Oct 7, 2019 at 2:11 PM Mike Taylor  wrote:


Hi Rick,

On 9/28/19 10:07 PM, Rick Byers wrote:

Can you give us a week or so to chat about this within the Chrome team
and get back to you?


Any updates here?

Thanks.

--
Mike Taylor
Web Compat, Mozilla


--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to blink-dev+unsubscr...@chromium.org.
To view this 

Re: [webkit-dev] [blink-dev] Re: What to do about scroll anchoring?

[Emilio Cobos Álvarez]

On 9/29/19 5:07 AM, Rick Byers wrote:
On Fri, Sep 27, 2019 at 10:16 AM Emilio Cobos Álvarez 
mailto:emi...@mozilla.com>> wrote:


Hi Steve,

On 9/27/19 4:03 PM, Steve Kobes wrote:
 > Hi Emilio,
 >
 > My recollection is that scroll anchoring was, in fact, a mess.  I
do not
 > personally have any opinion about whether scroll anchoring should be
 > removed from Gecko.
 >
 > We (Chrome) decided to accept some compat issues for the sake of
 > launching the feature.  This was a judgment call and could
reasonably
 > have gone the other way.

Right, my concern is that taking compat fallout with Chrome's market
share may be acceptable, because people will likely fix their websites
if they misbehave.

But web developers may not take the same time to fix their site if it's
broken on Firefox for Android, for example, which in turn drives
Firefox
users away (and you know this is a vicious cycle, the less users you
have, the less people will care about fixing their websites in your
browser).

That being said, more generally, I care about being interoperable /
predictable here for web developers, and seems like that ship may have
sailed if we need to fix some Gecko-specific issues by tweaking our
heuristics, but Chromium / Blink doesn't change them in the same way
(which is understandable, I guess, though I've filed spec issues for
our
reasoning behind these changes, which I think would apply to Chrome as
well).


FWIW, I agree with this principle. I'm sorry you've had to do a lot of 
compat work on this Emilio. Are you saying you've found many cases where 
chromium's behavior doesn't match the spec / web-platform-tests and the 
different is relevant to real-world website compat (forcing you to 
invest in "bug-for-bug compatibility")? That would definitely make me 
very sad. Or is the issue more about compat with sites which have 
UA-conditional behavior (either explicit or implicit based on some other 
Gecko/blink difference?).


Well, part of it is that. The initial implementation took a lot of just 
figuring out what Chromium was doing rather than implementing the spec, 
because the spec had clear issues (like referencing the DOM rather than 
layout stuff).


Some of them like [1] were pretty obvious and were caught during our 
initial implementation of the feature. Others like [2] Ryan probably 
found by testing Chromium's behavior.


Some other still pretty significant behavior differences were only 
caught later by me and people finding compat issues in the wild, like 
[3]. I was sad that the spec reflected absolutely nothing like what 
Blink implements. For this issue in particular, Blink roughly uses 
"whatever inherits from LayoutBox can be an anchor", which is obviously 
not something that you can reasonably spec, and definitely not "block 
boxes and text", which is what the spec said.


Those are off the top of my head, Ryan probably has more examples.

IMHO In general, either an initially chromium-only feature is valuable 
enough that we should continue to invest as necessary to achieve interop 
with other engines when they implement (eg. adding web-platform-tests 
and improving the spec for the inevitable cases that appear with a 
second implementation), or we should decide the feature isn't worth the 
cost to properly support on the web at large and remove it from chromium.


Steve is the expert and can probably elaborate on details, but IIRC the 
real world web compat constraints of scroll anchoring ended up requiring 
a number of tough tradeoffs. If you're learning about new web compat 
constraints, then it's entirely possible that the cost/benefit equation 
is now different and we should be re-evaluating whether it still makes 
sense to keep scroll anchoring in chromium. Like David I like the 
feature - but only to the extent that it works alright for most of the 
web as it exists today, and developers can reliably reason about it (eg. 
by replacing any heuristics designed under the constraints of web-compat 
with explicit APIs).


Can you give us a week or so to chat about this within the Chrome team 
and get back to you?


Thanks, and sorry again for the frustration. When we ship a feature 
first in chromium, it's always our intent that subsequent compatible 
implementations should be MUCH easier to ship (it's one of the main 
reasons we invest so much in web-platform-tests).


Sure, no worries, and thanks for the reply.

 -- Emilio

[1]: https://github.com/w3c/csswg-drafts/issues/3480
[2]: https://github.com/w3c/csswg-drafts/issues/3319
[3]: https://github.com/w3c/csswg-drafts/issues/4247



   -- Emilio

 > On Fri, 27 Sep 2019 at 09:09, Emilio Cobos Álvarez
mailto:emi...@mozilla.com>
 > <mailto:emi...@mozilla.com <mailto:emi...@mozilla.com>>> wrote:
 >
 >     And, 

Re: [webkit-dev] [blink-dev] Re: What to do about scroll anchoring?

[Emilio Cobos Álvarez]

Hi Steve,

On 9/27/19 4:03 PM, Steve Kobes wrote:

Hi Emilio,

My recollection is that scroll anchoring was, in fact, a mess.  I do not 
personally have any opinion about whether scroll anchoring should be 
removed from Gecko.


We (Chrome) decided to accept some compat issues for the sake of 
launching the feature.  This was a judgment call and could reasonably 
have gone the other way.


Right, my concern is that taking compat fallout with Chrome's market 
share may be acceptable, because people will likely fix their websites 
if they misbehave.


But web developers may not take the same time to fix their site if it's 
broken on Firefox for Android, for example, which in turn drives Firefox 
users away (and you know this is a vicious cycle, the less users you 
have, the less people will care about fixing their websites in your 
browser).


That being said, more generally, I care about being interoperable / 
predictable here for web developers, and seems like that ship may have 
sailed if we need to fix some Gecko-specific issues by tweaking our 
heuristics, but Chromium / Blink doesn't change them in the same way 
(which is understandable, I guess, though I've filed spec issues for our 
reasoning behind these changes, which I think would apply to Chrome as 
well).


 -- Emilio

On Fri, 27 Sep 2019 at 09:09, Emilio Cobos Álvarez <mailto:emi...@mozilla.com>> wrote:


And, to be clear, we _can_ fix these compat issues, some way or another.

One thought is to limit the amount of scroll adjustments without user
scrolling or stuff like that, which would prevent the "you get stuck on
the page".

Making anchoring opt-in rather than opt-out is another option, but that
defeats most of the purpose of the feature, I guess.

See also some of the Chromium docs on the compat issues they found[1]
and how were they trying to fix them before adding the
"layout-affecting-property changed" heuristic, which is what is on the
spec right now and what they implement.

I just think that these are very hacky heuristics that are just
going to
bring a lot of compat pain and developer confusion.

It doesn't help that all these things can break or not depending on the
speed at which the user scrolls, the amount of scroll events that the
user dispatches, the timing of these events relative to other
events, etc...

   -- Emilio

[1]:

https://docs.google.com/document/d/1nQAO4MYCDMn0rTkn_-WI6gjumk3Qi2Bn-MGuB3NlVxE/edit

<https://docs.google.com/document/d/1nQAO4MYCDMn0rTkn_-WI6gjumk3Qi2Bn-MGuB3NlVxE/edit>

    On 9/27/19 2:23 PM, Emilio Cobos Álvarez wrote:
 > Hi,
 >
 > (cc'ing webkit-dev@ and blink-dev@ in case they have feedback or
 > opinions, as WebKit is the only engine which does not implement
scroll
 > anchoring, though I don't know if they plan to, and Blink is the
only
 > other engine that does implement it. Please reply to
dev-platform@ though.)
 >
 > TLDR: Scroll anchoring is really a mess.
 >
 > I didn't do the initial implementation of the feature in Gecko,
but I've
 > done a ton of work over the last few months to fix compat issues
in our
 > implementation (see all the bugs blocking [1]).
 >
 > At this point, our implementation is mostly compatible with
Blink, but
 > even with a bug-for-bug compatible implementation, we did get compat
 > issues because of different content being served for different
browsers,
 > or because our anti-tracking protections changing the final
content of
 > the page slightly ([2] is an example of bug which only reproduces
with
 > ETP enabled only, but whose reduced test-case renders the site
unusable
 > in Chrome as well).
 >
 > If you hit one of the broken cases as a user you think the
browser is
 > completely broken, and the site is just unusable.
 >
 > I've fixed those by tweaking the heuristics Gecko uses. Those extra
 > heuristics have also caused other compat issues, like [3], reported
 > today, which will require other adjustments to the heuristics, etc...
 >
 > On top of that, the spec is not in a good state, with ton of open
issues
 > without feedback from the editors [4].
 >
 > So right now I'm at a stage where I think that the feature is
just not
 > worth it. It doesn't behave predictably enough for developers,
and you
 > have no guarantee of it behaving consistently unless you test a
 > particular browser, with a particular content in a particular
viewport
 > size... That's not great given the current dominant position of
 > Chromium-based browsers.
 >
 > On top, issues with scroll anchoring are pretty hard to diagnose
unless
 

Re: [webkit-dev] What to do about scroll anchoring?

[Emilio Cobos Álvarez]

And, to be clear, we _can_ fix these compat issues, some way or another.

One thought is to limit the amount of scroll adjustments without user 
scrolling or stuff like that, which would prevent the "you get stuck on 
the page".


Making anchoring opt-in rather than opt-out is another option, but that 
defeats most of the purpose of the feature, I guess.


See also some of the Chromium docs on the compat issues they found[1] 
and how were they trying to fix them before adding the 
"layout-affecting-property changed" heuristic, which is what is on the 
spec right now and what they implement.


I just think that these are very hacky heuristics that are just going to 
bring a lot of compat pain and developer confusion.


It doesn't help that all these things can break or not depending on the 
speed at which the user scrolls, the amount of scroll events that the 
user dispatches, the timing of these events relative to other events, etc...


 -- Emilio

[1]: 
https://docs.google.com/document/d/1nQAO4MYCDMn0rTkn_-WI6gjumk3Qi2Bn-MGuB3NlVxE/edit


On 9/27/19 2:23 PM, Emilio Cobos Álvarez wrote:

Hi,

(cc'ing webkit-dev@ and blink-dev@ in case they have feedback or 
opinions, as WebKit is the only engine which does not implement scroll 
anchoring, though I don't know if they plan to, and Blink is the only 
other engine that does implement it. Please reply to dev-platform@ though.)


TLDR: Scroll anchoring is really a mess.

I didn't do the initial implementation of the feature in Gecko, but I've 
done a ton of work over the last few months to fix compat issues in our 
implementation (see all the bugs blocking [1]).


At this point, our implementation is mostly compatible with Blink, but 
even with a bug-for-bug compatible implementation, we did get compat 
issues because of different content being served for different browsers, 
or because our anti-tracking protections changing the final content of 
the page slightly ([2] is an example of bug which only reproduces with 
ETP enabled only, but whose reduced test-case renders the site unusable 
in Chrome as well).


If you hit one of the broken cases as a user you think the browser is 
completely broken, and the site is just unusable.


I've fixed those by tweaking the heuristics Gecko uses. Those extra 
heuristics have also caused other compat issues, like [3], reported 
today, which will require other adjustments to the heuristics, etc...


On top of that, the spec is not in a good state, with ton of open issues 
without feedback from the editors [4].


So right now I'm at a stage where I think that the feature is just not 
worth it. It doesn't behave predictably enough for developers, and you 
have no guarantee of it behaving consistently unless you test a 
particular browser, with a particular content in a particular viewport 
size... That's not great given the current dominant position of 
Chromium-based browsers.


On top, issues with scroll anchoring are pretty hard to diagnose unless 
you're aware of the feature.


All in all, it doesn't seem like the kind of feature that benefits a 
diverse web (nor web developers for that matter), and I think we should 
remove the feature from Gecko.


Does anyone have strong opinions against removing scroll anchoring from 
Gecko, based on the above?


Thanks,

  -- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1519644
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1561450
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1584499
[4]: https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1
___
dev-platform mailing list
dev-platf...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] What to do about scroll anchoring?

[Emilio Cobos Álvarez]

Hi,

(cc'ing webkit-dev@ and blink-dev@ in case they have feedback or 
opinions, as WebKit is the only engine which does not implement scroll 
anchoring, though I don't know if they plan to, and Blink is the only 
other engine that does implement it. Please reply to dev-platform@ though.)


TLDR: Scroll anchoring is really a mess.

I didn't do the initial implementation of the feature in Gecko, but I've 
done a ton of work over the last few months to fix compat issues in our 
implementation (see all the bugs blocking [1]).


At this point, our implementation is mostly compatible with Blink, but 
even with a bug-for-bug compatible implementation, we did get compat 
issues because of different content being served for different browsers, 
or because our anti-tracking protections changing the final content of 
the page slightly ([2] is an example of bug which only reproduces with 
ETP enabled only, but whose reduced test-case renders the site unusable 
in Chrome as well).


If you hit one of the broken cases as a user you think the browser is 
completely broken, and the site is just unusable.


I've fixed those by tweaking the heuristics Gecko uses. Those extra 
heuristics have also caused other compat issues, like [3], reported 
today, which will require other adjustments to the heuristics, etc...


On top of that, the spec is not in a good state, with ton of open issues 
without feedback from the editors [4].


So right now I'm at a stage where I think that the feature is just not 
worth it. It doesn't behave predictably enough for developers, and you 
have no guarantee of it behaving consistently unless you test a 
particular browser, with a particular content in a particular viewport 
size... That's not great given the current dominant position of 
Chromium-based browsers.


On top, issues with scroll anchoring are pretty hard to diagnose unless 
you're aware of the feature.


All in all, it doesn't seem like the kind of feature that benefits a 
diverse web (nor web developers for that matter), and I think we should 
remove the feature from Gecko.


Does anyone have strong opinions against removing scroll anchoring from 
Gecko, based on the above?


Thanks,

 -- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1519644
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1561450
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1584499
[4]: https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] -Wpessimizing-move and -Wredundant-move

[Emilio Cobos Álvarez]

On 19/03/2019 00:56, Michael Catanzaro wrote:
> On Mon, Mar 18, 2019 at 4:43 PM, Andy Estes  wrote:
>> FWIW, Apple’s ports use the equivalent clang warning for pessimizing
>> and redundant moves, and we cleaned up a bunch of these mistakes in
>> our ports a few years ago. Hopefully you aren’t finding any of these
>> mistakes in shared code.
> 
> There are a lot, actually. Maybe clang only has -Wpessimizing-move
> (which caused relatively few warnings) and not -Wredundant-move (which
> caused very many). I'm not actually sure what the difference is; in both
> cases, a local variable is cast to rvalue reference via std::move before
> it is returned.

IIRC, clang only warns when using std::move, not a similarly defined
function (like WTFMove, presumably).

In Gecko, when I switched from mozilla::Move to std::move [1], I had to
disable the warning and fix all of them in a followup, since clang
didn't use to warn about them.

If gcc is able to warn more generally, that may explain what you're seeing.

 -- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1465585
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Huge improvement in Safari results on wpt.fyi

[Emilio Cobos Álvarez]

On 10/12/18 3:59 AM, Geoffrey Garen wrote:

Honest question: What’s gross about using @font-face?

It would be lots of test edits. That’s a bummer.

But maybe it’s clearer for the tests to specify the font they want to use. It 
makes the test self-describing, eliminating the requirement that the user take 
a step outside the test to get the right result.


Note that there's also the opposite opinion of loading a web font 
potentially hiding bugs:


  https://lists.w3.org/Archives/Public/www-style/2017Jan/0053.html

Though I don't have such a strong opinion myself, I think @font-face is 
a fine solution for that problem (and other people seemed to be ok with 
that as well, looking at how that thread continues...).


I don't know if the CSSWG ended up taking an official position on this, 
but may be worth asking in www-style before doing he work of a mass-convert.


 -- Emilio


Thanks,
Geoff


On Oct 11, 2018, at 6:01 PM, Dean Jackson  wrote:

It turns out that many (most?) of the CSS failures are because we no longer 
expose user-installed fonts, e.g. Ahem.

Options:

- update lots of tests to load Ahem via @font-face (yuck)
- allow Ahem to be used if installed (weird to special case one font, but 
probably ok)

Dean


On 12 Oct 2018, at 03:26, Philip Jägenstedt  wrote:

Alright, I've written a one-off script [1] to find the Safari-only
failures, and here's the output:
https://gist.github.com/foolip/4d410ce79416bcdce71feb212159a02e

Barring bugs, each of linked tests or one of its subtests should be
failing in Safari Technology Preview and passing in stable versions of
Chrome, Edge and Firefox.

Numerically, most of the failures are in css (622), encoding (135) and
html (60). With css, it's mostly css/CSS2.

I hope looking through this may be of use to you!

[1] https://github.com/foolip/ad-hoc-wpt-results-analysis

On Mon, Oct 8, 2018 at 11:50 PM Philip Jägenstedt  wrote:


That filtering capability unfortunately does not yet exist on wpt.fyi
but it's a high priority and actively being worked on:
https://github.com/web-platform-tests/wpt.fyi/issues/201

FWIW, I suspect that these purposes, comparing to the stable versions
of all *other* browsers might be the most useful:
https://wpt.fyi/results/?product=chrome%5Bstable%5D=edge%5Bstable%5D=firefox%5Bstable%5D=safari%5Bexperimental%5D

Again, no way to filter on wpt.fyi, but I'll see if I can download the
full results and write a quick script.

On Thu, Oct 4, 2018 at 11:49 PM Ryosuke Niwa  wrote:


Thanks for the intriguing data, Philip.

Is there a way to get a list of tests where all other browsers pass but Safari 
/ WebKit fail?

That would allow us to quickly identify the set of tests we can fix to improve 
the interoperability across browsers right away.

- R. Niwa

On Tue, Oct 2, 2018 at 3:45 AM Philip Jägenstedt  wrote:


Hi WebKittens,

Fresh off the bots, I'm excited to report more robust Safari results,
and that Safari WPT pass rates are clearly improving! Thanks to the
hard work of Mike Pennisi [1] we now have the first Safari 12 results:
https://wpt.fyi/results/?sha=ee2e69bfb1=safari-12.0

This uses the same setup as for Safari Technology Preview, which has
been running for a while [2] and are the results you see on the
"experimental" view:
https://wpt.fyi/results/?label=experimental

This appears much more robust than the Safari 11 data we've collected
from Sauce Labs, and we can see a massive improvement between Safari
11 and 12:
https://wpt.fyi/results/?sha=ee2e69bfb1=safari-11.1=safari-12.0

This lumps together infrastructure improvements as well as Safari
11->12 improvements, but improvements in service-workers/ [3] stands
out, as well as in webdriver/, referrer-policy/, css/css-align/, and
others. (The effect of moving away from Sauce is mainly less
timeouts.)

Also very interesting is to compare Safari 12 stable to TP:
https://wpt.fyi/results/?sha=ee2e69bfb1=safari-12.0=safari-12.1

One can tell that work is going in canvas-related things,
web-animations/, css/css-logical/ and more! \o/

I hope you'll all find these results valuable, and please report bugs
or feature requests here:
https://github.com/web-platform-tests/wpt.fyi/issues

P.S. We're also trying to use use these diff views to spot
regressions. It's a bit hard to use, [4] but a fix in in progress [5]
and I might check back here when that works. I'll append to the end of
this email a non-exhaustive list of possible regressions already
possible to spot.

[1] https://github.com/web-platform-tests/results-collection/issues/604
[2] https://wpt.fyi/test-runs?labels=safari,experimental
[3] 
https://wpt.fyi/results/service-workers?sha=ee2e69bfb1=safari-11.1=safari-12.0=true
[4] https://github.com/web-platform-tests/wpt.fyi/issues/411
[5] https://github.com/web-platform-tests/wpt.fyi/pull/609

P.P.S. Possible regressions in Safari TP:
https://wpt.fyi/results/css/vendor-imports/mozilla/mozilla-central-reftests/shapes1?sha=ee2e69bfb1=safari-12.0=safari-12.1