sounds like regression, could you help to bisect?

Adding needs-bisect label to request a bisection.

alex7kom@ I don't think we can reasonably reproduce this without a link to HTML with the font specified in CSS (as requested on the github issue). We appreciate your help debugging this.

Adding needs-feedback for this reason.

We are closing this issue due to lack of feedback.

If you are still seeing the issue or have new data, please file a new bug and provide the steps to reproduce the issue, OS, Chrome details, sample file/ .apk file that would be helpful in triaging the issue from our end.

Hi there - sorry this took a while, I just added debugging support related to this issue in our app, so we can help reproduce. Would you consider taking another look? You can easily get the HTML and attach remote webview debugging to an emulator now - and we have the data required to reproduce plus information here: https://github.com/ankidroid/Anki-Android/issues/4856

Hi Mike. We actually already have the ability to inspect the HTML (it's enabled regardless of setWebContentsDebuggingEnabled() when on debuggable devices). The issue is that we don't know how to reproduce this specific issue (we aren't users of your app).

If you can reproduce it, can you attach an HTML file to this bug report to repro the issue? We can solve this much quicker that way (even better if you can get this problem to repro in either Android or Desktop Chrome).

Thanks very much Nate - I'm trying to see if one of our affected users is able to be the main participant in the troubleshooting feedback loop, if not I'll back-stop and get HTML to you

We appear to have HTML? cross-posting from here: https://github.com/ankidroid/Anki-Android/issues/4856#issuecomment-429413616

This is from one of our users, hopefully it is a format that works if not please be very specific about how to construct the test case. Thank you!

Deleted: card.zip 1.6 KB

card.zip 1.6 KB Download

Took a look, but I don't anything suspicous (see screenshot and video).

I tried this with a couple webview versions, including 68.0.3440.70 (as per report).

Could this be related to websettings or callback overrides in your app?

Deleted: 2018-10-12_15-40-49_droidshot_J5fnU.png 141 KB

	2018-10-12_15-40-49_droidshot_J5fnU.png 141 KB View Download

Deleted: demo.mp4 2.4 MB

	demo.mp4 2.4 MB View Download

Looks like this is a "good" one. I'll check and if I can reproduce I'll try backing out whatever we are doing in app to isolate. Thanks for looking 

I can reproduce it in Chrome current apt repo on ubuntu 18.04LTS ("Version 69.0.3497.100 (Official Build) unknown (64-bit)")

My hunch is that when you did the repro attempt on the cards above you didn't have the font in the directory because I don't think we provided a font...

Here's a slow.html and fast.html along with the font that triggers it in slow.html (fast.html relies on system font). It looks like it's doing some sort of double-render (reflow? I'm not a web engineer) and I see the same in the webview in our app.

Hope this helps?

Deleted: Chrome_Example.zip 10.3 MB

Chrome_Example.zip 10.3 MB Download

Might have a repro?

Deleted: slow-font-repro.mp4 3.0 MB

	slow-font-repro.mp4 3.0 MB View Download

That's it! I can see the fonts are different and that is the speed difference we see as well. It isn't ridiculous but our app attracts dedicated intelligent people that want to go through flashcards as fast as possible, so they noticed ;-). I'm listening here but I don't think you need anything else from me? I can say that this happened with various Chinese or Japanese fonts - we had reports of the problem from more than one font.

Seems a bit slower to me too. I guess this may be a bug, although I haven't confirmed if this was a regression.

I'd like to upload the APK, but it's too big to attach (I'll look into that).

From the associated tracker, WebView 55 works, WebView 67+ does not, somewhere in a bisect between the two it should change.

Additional information from a user was "Card also flashes whenever this happen. CSS styling also doesn't load properly due to this.". Note that "card" for us is an Android app with a webview embedded, rendering HTML with associated CSS and Javascript where the CSS is under user control so I can't say what they're loading unfortunately. Thanks for sticking with this one

Studio is building massive APKs. Best size I can get to is 14M, which is too big for crbug.

APK lives in https://drive.google.com/drive/folders/1GkjqlbAIBHEPR_mTwkgFzZKHJ4VwHwSt?usp=sharing (Google only, sorry)

I think I can also repro on Desktop Chrome, so I'm removing the WebView component.

Steps in desktop chrome:
1. Unzip Chrome_Example.zip from comment #12
2. Step into the folder, execute `python -m SimpleHTTPServer`
3. Navigate 2 browser tabs. One to http://127.0.0.1:8080/fast.html and one to http://127.0.0.1:8080/slow.html
4. use ctrl-f5 a few times on each tab, to refresh the page. Observe the fast.html refreshes almost instantly, with very little flicker. Observe slow.html takes slightly longer to refresh.

Blink team: can you confirm if this is expected behavior?

When using web fonts, unless the font has already been loaded by the time the content is encountered, it will firts be rendered with a fallback font and then, once the font has loaded, again with the web font.

This takes, at least, twice the amount of time as rendering with a system font and is to be expected. Often performance is much worse as web fonts tend to be poorly optimized.

The loading behavior can be customized using font-display.
https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-display

...and  yet - this was not detected by users with the same HTML/CSS/JS content in WebView 55.0.2883.91 as mentioned in the original bug, so performance wise for the same font + content this seems like a performance regression?

That said, maybe `font-display: block` would be useful as it would tell the rendering engine to commit to the downloaded font and not waste time (possible performance) on rendering a fallback?