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

2020-02-20 Thread 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 . Let's 
discuss there.

On Tue, Oct 29, 2019 at 3:03 PM Emilio Cobos Álvarez > 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
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
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
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
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?


   -- Emilio



 > 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
 >> 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 

Re: [webkit-dev] Request for position on Badging API

2020-02-20 Thread Ryosuke Niwa
On Wed, Feb 19, 2020 at 4:32 PM Matt Giuca  wrote:

> On Thu, 20 Feb 2020 at 11:18, Ryosuke Niwa  wrote:
>> On Wed, Feb 19, 2020 at 3:29 PM Matt Giuca  wrote:
>>> On Wed, 19 Feb 2020 at 18:14, Ryosuke Niwa  wrote:

 On Tue, Feb 18, 2020 at 4:02 PM Matt Giuca  wrote:

> Thanks for the replies. Folding both Dean and Ryosuke's emails into
> one.
> On Mon, 17 Feb 2020 at 03:03, Dean Jackson  wrote:
>> Not speaking for all of WebKit, and definitely not all of Apple, but
>> I think this seems like a good idea.
>> I'm not sure I get the distinction between app badges and document
>> badges though. I'd also like to see some specification text describing 
>> how
>> the browser should ignore multiple set/clear operations executed in rapid
>> succession (e.g. to create a blinking badge) - maybe the limit is one 
>> badge
>> operation per minute or something?
> Good suggestion. Filed an issue:
> Also, given that the main use case for this would be alerting the user
>> to a notification, it seems like it should be able to link it directly to
>> that. This would provide the ability for a push notification to trigger 
>> the
>> badge without ever firing up the page context.
> I'm not sure what you mean by "link directly to that". We've
> deliberately specified this as separate to notifications (since you may or
> may not want the badge to be set without one). If you want to show a
> notification and a badge at the same time, you can use both APIs together.
> If you want to have a push notification set the badge when the service
> worker runs, you can do that (but as has been discussed at length:
>, you *can't* currently set
> a badge without a notification from a push message).
> On Mon, 17 Feb 2020 at 03:49, Ryosuke Niwa  wrote:
>> For the record, we have two concerns raised internally at Apple:
>>  * The integration of this API with push service worker would require
>> running scripts in order to update the badge. This will pose a serious
>> power consumption issue.
> That isn't a feature of the current proposal. The spec doesn't give
> service worker push any new capabilities that it didn't already have (in
> particular, if the browser requires the push message to show a
> notification, that is still true; you simply cannot set a badge from a 
> push
> message without showing a notification). See
> and
> .
> This is something we've given some thought to. We (Google) would like
> to eventually see it possible to set a badge in the background without a
> notification. But the power consumption and privacy issues are well known,
> and at this stage, it is not being proposed.

 Because all background processes (including non-foreground tabs) are
 suspend on iOS, this makes this feature pretty much useless. If the user is
 currently seeing a website, then there is no need for updating the badge
 since the user is already there. On the other hand, if the user isn't
 currently seeing the website, then the website' scripts are never gonna 

>>> I see. So it sounds like this API would be useful but only once combined
>>> with a future proposal to let badges be set via push.

  * We don’t want every website to start using this API to increase
>> “engagement”.
> Do you mean as a way of drawing additional attention to itself? Well,
> the setAppBadge API can only be used by installed applications, so that
> doesn't apply to every site the user might visit. And the user agent / OS
> can provide the user with UI to suppress badges on a per-app basis if an
> app is too spammy. The setClientBadge API could be used by any website to
> draw attention, but the user agent should make the badge sufficiently
> subtle that this is no more abusive than a favicon, which can already be
> used to show a pseudo-badge.

 Since there is not a concept of installed web apps in Safari on macOS,
 this isn't going to work there.

>>> The setClientBadge API still makes sense on Safari on macOS.
>> It doesn't because we don't have a concept of installed apps, and we
>> don't want to let any website use this API as that may annoy users.
> I just want to be clear about what setClientBadge is for. (And note that
> nobody has implemented this yet; it's just in the draft spec as proposed by
> Marcos Caceres from Firefox.)
> This has nothing to do with installed apps. It's just about being able to
> badge the current