1901451 - checkerboarding easier to trigger with long running main thread resize event handler

Status: NEW

(Core :: Panning and Zooming, defect, P3)

Description

[Timothy Nikkel (:tnikkel)]

On Android. Goto https://mods.mb.ca/ scroll up or down to show or hide the toolbar, then continue scrolling. You will experience a long event of checkerboarding. This is caused because of a long reflow (2 seconds) that is caused by js on the page in response to the resize event from showing/hiding the toolbar.

On Chrome the checkerboard is much much less severe. I haven't checked why, do they complete the reflow much quicker? Or something else?

The long reflow can be observed on desktop too, but resize events don't happen like they do on mobile so it's not as big a deal.

Comment 1

[Timothy Nikkel (:tnikkel)]

Also, the reflow doesn't actually change anything because site only makes changes to the page in response to the width changing.

Comment 2

[Timothy Nikkel (:tnikkel)]

Potential ways to look into this: do we send the resize event more often when hiding/showing the toolbar? Is Chrome reflowing faster than us? If so, what can we do better? Is Chrome's reflow also long but they don't checkerboard as much, then why? It looks like they might be able to draw the background image of a div instead of just plain checkerboarding, but that doesn't seem to be the only thing.

Comment 3

[Emilio Cobos Álvarez [:emilio]]

I can repro, do you happen to have a profile around tho? (I can't profile easily on Android right now).

I assume this is the "VisualViewport.resize" event, not the window resize event, if the later fires that'd be a bug.

Comment 4

[Timothy Nikkel (:tnikkel)]

Android profile
https://profiler.firefox.com/public/2n63966tv7n6s7c3eb2vvfrqv353fnqhv0a9hq0

I also compared reflow times on desktop between Chrome and Firefox, it's maybe 1s for Chrome and 1.2s for Firefox. So the reflow also takes about as long in Chrome. So maybe it's not about the reflow so much.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

I assume this is the "VisualViewport.resize" event, not the window resize event, if the later fires that'd be a bug.

No, this is the window.resize event. I made a test page, both Firefox and Chrome send the window.resize event when hiding/showing the toolbar.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Timothy Nikkel (:tnikkel) from comment #1)

Also, the reflow doesn't actually change anything because site only makes changes to the page in response to the width changing.

(this seems to be true from a visual perspective; however, the site does seem to mess with CSS width values even in response to height changes, such that it ends up creating a slow reflow on viewport height-changes, in Firefox as well as Chrome).

(In reply to Timothy Nikkel (:tnikkel) from comment #0)

On Chrome the checkerboard is much much less severe. I haven't checked why, do they complete the reflow much quicker? Or something else?

This matches my perception on my Pixel 8 phone, too. I'm not experienced with profiling Chrome on Android, but I used their "record trace" button (in developer section of settings), which gave me a file that I could load in https://ui.perfetto.dev, and then convert to JSON from there (which I was then able to upload to our profiler UI).

That resulted in this profile: https://share.firefox.dev/3XRY0P9 , which does show ~1s-long jank from "resize" events (but I'm not seeing those visually; they're not obviously checkerboarding when I look at the phone). So I'm guessing their APZ system is handling this better than ours, since it's somehow tolerating these ~1-second-janks better than we are.

I should also note that this isn't a single reflow; if you drill down into the profile from comment 4, you can see that the site is repeated setting the width of some element and then flushing layout, in rapid succession. So this is many small forced reflows (with style being invalidated between each one) rather than one large reflow. (And it all blocks the main thread because it's happening in a synchronous callback from the resize event).

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #5)

So I'm guessing their APZ system is handling this better than ours, since it's somehow tolerating these ~1-second-janks better than we are.

(--> Reclassifying to APZ based on this^ observation)

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (intentionally janks for 2s on window resize, so that you can see what sort of checkerboarding results from that)

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: screencast showing testcase 1 in Chrome vs. Firefox Nightly (on Pixel 6a Android phone)

Comment 9

[Daniel Holbert [:dholbert]]

Attached testcase/screencast are meant to get to the heart of the issue here; when a page spends several seconds in an invocation of its window.addEventListener("resize", () => {...}) handler, Chrome mostly still manages to avoid checkerboarding, whereas Firefox checkerboards much more readily.

Comment 10

[Botond Ballo [:botond]]

Added to APZ Performance Sprint (FFXP-2745) for investigation.

Comment 11

[Hiroyuki Ikezoe (:hiro)]

(In reply to Timothy Nikkel (:tnikkel) from comment #2)

Potential ways to look into this: do we send the resize event more often when hiding/showing the toolbar?

As far as I can tell the number of events are same both on Chrome and Firefox. A big difference here is that;

On Firefox a resize event gets fired immediately after the toolbar is hidden/shown.
On Chrome a resize event gets fired after scrolling has finished.

I think this difference makes the checkerboarding more noticeable. I.e. on Chrome if the user keeps scrolling, no resize event happens during scrolling.

Comment 12

[Hiroyuki Ikezoe (:hiro)]

FWIW, on Safari there are multiple resize events while the toolbar is moving.

Comment 13

[Botond Ballo [:botond]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #11)

A big difference here is that;

On Firefox a resize event gets fired immediately after the toolbar is hidden/shown.
On Chrome a resize event gets fired after scrolling has finished.

Sounds like maybe bug 1918244.

Comment 14

[Hiroyuki Ikezoe (:hiro)]

Yeah, I think it is.