New issue
Advanced search Search tips

Issue 740765 link

Starred by 3 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

Unsmooth scrolling when blocking web fonts on reddit.com

Reported by mcome...@mozilla.com, Jul 11 2017

Issue description

Example URL:
https://www.reddit.com/r/todayilearned/comments/6mgzgu/til_muhammad_ali_was_stripped_of_his_heavyweight/

Steps to reproduce the problem:
1. Connect an Android device with Chrome installed to your computer (we're going to use the mobile dev tools)
2. Open mobile chrome, go to a reddit page with comments
3. Open Chrome dev tools -> click Remote Devices on the bottom, select your device (on the left), and click inspect for the reddit page
4. Open the "Network pane" -> Click "Font"
5. Reload the page to get web fonts to load
6. Right-click on any loaded fonts, select "Block Request URL", & refresh the page to reload with request blocked
7. Repeat previous step until no fonts are loaded.
8. Scroll down the contents of the page

What is the expected behavior?
Scrolling is smooth

What went wrong?
Scrolling isn't smooth (but is smooth on this page before the web fonts are blocked).

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 59.0.3071.125 (Official Build) (32-bit)  Channel: stable
OS Version: 6.0.1
Flash Version: 

This occurs on multiple reddit pages with comments and I suspect it could happen on other pages.

I took a video of me reproducing the issue. The first page load is without blocking web fonts & the second page load is with web fonts blocked. Note that the effect is more pronounced on device where the smooth scrolling is more noticeable under finger. Video here: https://www.youtube.com/watch?v=QA5Ymg9L_P4&feature=youtu.be

I can reproduce on desktop but the effect is not as dramatic (presumably due to increased processing power).

We encountered this issue when developing Firefox Focus [1], which is based on the WebView APIs – we are tracking this issue at [2]. Focus is a privacy-focused browser, which has a settings option to block Web Fonts and this issue is easy to reproduce with that option enabled (the STR in Focus is at [3]). This issue makes Focus hard to use with Web Fonts blocked on sites like reddit.com.

Even if a fix for this issue is not prioritized, it'd be great to know why it's happening so we could try to come up with work-arounds. Thanks!

[1]: https://github.com/mozilla-mobile/focus-android
[2]: https://github.com/mozilla-mobile/focus-android/issues/816
[3]: https://github.com/mozilla-mobile/focus-android/issues/816#issuecomment-314264788
 
> I can reproduce on desktop but the effect is not as dramatic (presumably due to increased processing power).

This is only in responsive design mode – there don't seem to be any web fonts in non-responsive design mode.
Components: -Blink Blink>Scroll

Comment 3 by bokan@chromium.org, Jul 20 2017

Cc: bokan@chromium.org
Labels: Hotlist-Input-Dev
Hi mcomella@, I haven't had a chance to confirm the bug yet, but in the mean time, could you capture a trace I could take a look at? That might highlight what we're spending our time doing when you block web fonts.

Instructions are here: https://www.chromium.org/developers/how-tos/submitting-a-performance-bug (For android you'll need the "advanced instructions" link. tl;dr: chrome://inspect?tracing and use the "trace" link.
I've attached a trace where my example URL (from comment 0) [1] was already loaded with web fonts blocked and, while recording, I scroll down a few times.

I manually selected all categories but did not add any "disabled by default" categories - let me know if there's more I can do!

[1]: https://www.reddit.com/r/todayilearned/comments/6mgzgu/til_muhammad_ali_was_stripped_of_his_heavyweight/
trace_reddit-block-web-fonts.tar.gz
4.1 MB Download

Comment 5 by bokan@chromium.org, Jul 31 2017

Components: -Blink>Scroll Blink>Compositing Blink>Paint
Labels: -Hotlist-Input-Dev
Status: Untriaged (was: Unconfirmed)
Thanks, I actually couldn't get the trace to open but I took my own. I've attached both "good" (i.e. scrolling before blocking any fonts) and "bad" (after blocking fonts). (Note: I had to manually compress them and then they don't open from chrome://tracing as tar.gz so you have to extract and load the bare .json file, I think that's why I couldn't open the trace in #4).

The main thing that jumps out at me from the traces is that we're spending ~50ms doing UpdateLayerTree on each scroll update. We also spend ~10ms on FrameView::paintTree. Compositor thread is also running much longer tasks but presumably that's because it's getting some tough input from Blink.

Adding labels for Paint/Compositing team to take a look.

Comment 6 by bokan@chromium.org, Jul 31 2017

Forgot to attach traces
trace_webfonts.json.tar.gz
4.6 MB Download
trace_webfonts_good.json.tar.gz
2.5 MB Download
Components: -Blink>Compositing -Blink>Paint Blink>Fonts
Labels: PaintTeamTriaged-20170801 BugSource-User
All I can think of is that we are somehow waiting for font stuff to happen during painting, and we keep trying because the font is blocked.

I'm passing this to the font team so they can add information on the internal effects of blocking a web font URL. Specifically, what does the font system do when a font is requested but has been blocked?

Comment 8 by e...@chromium.org, Aug 2 2017

Components: -Blink>Fonts Blink>WebFonts

Sign in to add a comment