unnecessary reflows being triggered on autosport.com

RESOLVED INCOMPLETE

Status

()

Core
Layout
--
major
RESOLVED INCOMPLETE
5 years ago
2 years ago

People

(Reporter: wesj, Unassigned)

Tracking

(Blocks: 1 bug, {regression})

unspecified
ARM
Android
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox15 unaffected, firefox16 fixed, firefox17 fixed, fennec-)

Details

(URL)

(Reporter)

Description

5 years ago
+++ This bug was initially created as a clone of Bug #778333 +++
+++ This bug was initially created as a clone of Bug #775372 +++

In bug 778333 we saw a race occurring in Fennec because touchevents are taking a long time to fire on the webpage. That delay is being caused by a simple timer on the page:

div.innerHTML = someTimeString

which is triggering constant reflows and repaints of the entire page:
http://people.mozilla.com/%7Ebgirard/cleopatra/?report=fdb8e6900f04f16e2e3e9ae0c2c1e67338d78437

Need to do more debugging to see what exactly is scheduling the reflow, but it seems like this particular change should not be causing us to do this much work.
Well, changing innerHTML on some element will certainly trigger a reflow on the document root.  What happens after that depends on the exact frame structure of the page...
Wes, is this reproducible only on Fennec? Or does it happen on desktop as well?
(Reporter)

Comment 3

5 years ago
> Well, changing innerHTML on some element will certainly trigger a reflow on the document 
> root.  What happens after that depends on the exact frame structure of the page...

This page is mostly just a table driven layout from what I can see. I will try and build a reduced test case that shows this same problem. Just hoping this points to a set of problems we can optimize for, but probably need some deeper debugging to understand who's scheduling the reflows and why first? I have some old instructions from ehsan to help debug that, but any advice would be appreciated.

jwir3:
I ran the profiler on desktop and didn't see this same pattern, but I've never run the profiler on desktop before either. Maybe the same pattern exists but much faster so that its not showing as significant in the profile? I can try again and look a bit closer. Any advice on better ways to debug?
When you change the innerHTML, that will schedule a reflow, because the new content needs to be laid out.
tracking-fennec: ? → -
(In reply to comment #4)
> When you change the innerHTML, that will schedule a reflow, because the new
> content needs to be laid out.

Yes.  I think this bug is not really helpful in its current form since the reflow is definitely not unnecessary, but it would be useful to profile this and see what we're doing in the reflow process and if we can avoid some of that work.
No longer blocks: 753525
3+ year old bug without any significant updates since it was filed. Closing as incomplete.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Keywords: regressionwindow-wanted
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.