Last Comment Bug 779339 - unnecessary reflows being triggered on autosport.com
: unnecessary reflows being triggered on autosport.com
Status: RESOLVED INCOMPLETE
: regression
Product: Core
Classification: Components
Component: Layout (show other bugs)
: unspecified
: ARM Android
: -- major (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://autosport.com/
Depends on: 775372 778333
Blocks: 769857
  Show dependency treegraph
 
Reported: 2012-07-31 15:58 PDT by Wesley Johnston (:wesj)
Modified: 2015-10-12 14:21 PDT (History)
13 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
fixed
fixed
-


Attachments

Description Wesley Johnston (:wesj) 2012-07-31 15:58:11 PDT
+++ 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.
Comment 1 Boris Zbarsky [:bz] (Out June 25-July 6) 2012-07-31 18:53:58 PDT
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...
Comment 2 Scott Johnson (:jwir3) 2012-08-01 08:48:49 PDT
Wes, is this reproducible only on Fennec? Or does it happen on desktop as well?
Comment 3 Wesley Johnston (:wesj) 2012-08-01 14:33:19 PDT
> 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?
Comment 4 Boris Zbarsky [:bz] (Out June 25-July 6) 2012-08-01 21:10:41 PDT
When you change the innerHTML, that will schedule a reflow, because the new content needs to be laid out.
Comment 5 :Ehsan Akhgari (busy, don't ask for review please) 2012-08-09 12:01:03 PDT
(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.
Comment 6 Ryan VanderMeulen [:RyanVM] 2015-10-12 14:21:55 PDT
3+ year old bug without any significant updates since it was filed. Closing as incomplete.

Note You need to log in before you can comment on or make changes to this bug.