Closed Bug 779339 Opened 12 years ago Closed 9 years ago

unnecessary reflows being triggered on autosport.com

Categories

(Core :: Layout, defect)

ARM
Android
defect
Not set
major

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
firefox15 --- unaffected
firefox16 --- fixed
firefox17 --- fixed
fennec - ---

People

(Reporter: wesj, Unassigned)

References

()

Details

(Keywords: regression)

+++ 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?
> 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.
3+ year old bug without any significant updates since it was filed. Closing as incomplete.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.