Re: [webkit-dev] ios-wk2 EWS in a bad state because of flaky tests

2019-09-29 Thread Aakash Jain
This queue is back in good state. Please let me know if you notice any issue.

Thanks
Aakash

> On Sep 27, 2019, at 9:21 PM, Aakash Jain  wrote:
> 
> Hi All,
> 
> Last week we updated the iOS bots from iOS 12 to iOS 13. Since then we have 
> been noticing a lot of flaky tests. Because of that ios-wk2 queue has been in 
> a bad state. Most of the time, it is unable to determine if the test failures 
> were introduced by the patch or were pre-existing, and so it keep re-testing 
> the patch. Because of this various patches keep waiting for long time.
> 
> Me and few bot watchers are looking into these flaky failures, but it might 
> take a while to get the queue back to a good state. Meanwhile, if anyone of 
> you has any recent bugs assigned to you related to flaky tests, it would be 
> nice to prioritize that.
> 
> Thanks
> Aakash
> ___
> 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] What to do about scroll anchoring?

2019-09-29 Thread Simon Fraser

> On Sep 27, 2019, at 10:08 PM, Emilio Cobos Álvarez  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…


I expressed my main issue with scroll anchoring at the F2F, which is that it’s 
an on-by-default behavior that is making up for bad web authoring, and is 
harmful if only implemented by a subset of browsers.

I would support removing it entirely, or having it be opt-in.

Simon

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


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

2019-09-29 Thread 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>
 > >> wrote:
 >
 >     And, to be clear, we _can_ fix these compat issues, some way
or another.
 >
 >     One 

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

2019-09-29 Thread L. David Baron
On Friday 2019-09-27 14:23 +0200, Emilio Cobos Álvarez wrote:
> Does anyone have strong opinions against removing scroll anchoring from
> Gecko, based on the above?

It seems pretty sad, since I think it's a very useful feature for a
large class of pages -- particularly pages that are more "documents"
than "applications".

I wonder if it would be possible to disable the feature under
certain conditions, for example:
 * the page uses APIs that initiate scrolling from script, or
 * the page has handlers for scroll events, or
 * the page does both of the above
but leave the feature enabled for pages that don't do these things.

Based on what I've heard it seems like many of the cases where pages
are really broken involve some of those, although I haven't gone
through the bug lists.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2019-09-29 Thread L. David Baron
On Sunday 2019-09-29 10:54 +1000, Cameron McCormack wrote:
> How useful is scroll anchoring outside of the two cases mentioned in 
> https://drafts.csswg.org/css-scroll-anchoring/#intro i.e. images loading and 
> ad iframes being inserted?  Would it be feasible to make scroll anchoring a 
> much less general mechanism, and to scope it down to handling these specific 
> cases?

I think it's also quite useful for horizontal resizes of the browser
window (which can include device rotation on mobile, window
resizing/maximization on desktop, and also hiding/showing of browser
sidebar UI).

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2019-09-29 Thread 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 > 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



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