Re: [webkit-dev] Lazy loading

2019-10-29 Thread Scott Little
> Are there plans to better specify CSS background images lazy loading?

There aren't currently any plans to add lazy CSS background images to a
spec, or at least no plans that I know of right now.

Right now in Chromium, the default lazy loading behavior is essentially
based on whether or not the user has opted into Lite Mode (aka Data Saver),
so we've mostly been treating CSS background image lazy loading as kind of
an extra intervention or optimization to help these Lite Mode users save
more data.

Chromium code currently decides whether or not to lazily load CSS
background images according to the default lazy loading behavior, but if in
the future Chromium ever turns on automatic lazy loading as the default
behavior for non-Lite Mode users, we'd first either want lazy CSS
background images to be part of the spec, or we'd separate out lazy CSS
background images to be restricted to Lite Mode.

Cheers,
- Scott

On Mon, Oct 28, 2019 at 8:08 PM Rob Buis  wrote:

> > Regarding lazily loading CSS background images, Chromium determines whether
> > or not to lazily load CSS background images according to the default lazy
> > loading behavior, and isn't directly controlled by the "loading" attribute.
> > There are some heuristics involved, e.g. background images inside an iframe
> > that was itself lazily loaded are loaded eagerly for performance reasons,
> > but those heuristics are just part of the default lazy loading behavior.
>
> Scott, thanks for the clarification! Are there plans to better specify CSS
> background images lazy loading?
>
> Regards,
>
> Rob.
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] EWS now parses error logs in case of build failure

2019-10-29 Thread Aakash Jain
Hi Everyone,

I am happy to announce another EWS feature.

>From now on, in case of build failure, EWS will parse the errors and display 
>them in a separate 'errors' log. You wouldn't have to search through thousands 
>of lines of logs to find the error message.

For example, in https://ews-build.webkit.org/#/builders/16/builds/6054, in step 
#7 WebKit failed to compile. Complete logs (stdio) are 38,000+ lines, and the 
error is not at the end of the logs. Normally, it requires some searching 
through the logs to find the relevant errors. But now, there is another 
'errors' log, which contains just the relevant 11 lines (containing error and 
few related lines to provide additional context).

Hopefully this would save some time and efforts previously spent on searching 
through the large logs.

Note that this information is not displayed in status-bubble tool-tip, since 
this might be lot of text to display in the tooltip. My further plan is to make 
this information more readily available, by adding it to a custom designed page 
which will open on clicking the status bubble https://webkit.org/b/197522

Please let me know if you notice any issues or have any feedback.

Thanks
Aakash

Reference: https://webkit.org/b/203418
___
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-10-29 Thread 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] EWS now parses error logs in case of build failure

2019-10-29 Thread Ryosuke Niwa
These enhancements are great. There is one feature of the old EWS that I
really miss, which is that I used to get emails when some EWS failed. With
new EWS, I have to keep checking back the bugzilla to see if any of them
have failed periodically.

Can we add a feature to opt into such an email notification? Maybe a flag
on a patch or JSON configuration file somewhere.

- R. Niwa

On Tue, Oct 29, 2019 at 4:05 PM Aakash Jain  wrote:

> Hi Everyone,
>
> I am happy to announce another EWS feature.
>
> From now on, in case of build failure, EWS will parse the errors and
> display them in a separate 'errors' log. You wouldn't have to search
> through thousands of lines of logs to find the error message.
>
> For example, in https://ews-build.webkit.org/#/builders/16/builds/6054,
> in step #7 WebKit failed to compile. Complete logs (stdio) are 38,000+
> lines, and the error is not at the end of the logs. Normally, it requires
> some searching through the logs to find the relevant errors. But now, there
> is another 'errors' log, which contains just the relevant 11 lines
> (containing error and few related lines to provide additional context).
>
> Hopefully this would save some time and efforts previously spent on
> searching through the large logs.
>
> Note that this information is not displayed in status-bubble tool-tip,
> since this might be lot of text to display in the tooltip. My further plan
> is to make this information more readily available, by adding it to a
> custom designed page which will open on clicking the status bubble
> https://webkit.org/b/197522
>
> Please let me know if you notice any issues or have any feedback.
>
> Thanks
> Aakash
>
> Reference: https://webkit.org/b/203418
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
-- 
- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev