1278983 - Firefox performs relayout on mouse move causing site blinking

Status: NEW

(Core :: Layout, defect)

Description

[a.sergeev]

Attachment: index.html

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160604131506

Steps to reproduce:

Attached site fragment as standalone page. When I move mouse site is blinking. Here is a video:

http://screencast.com/t/4YtVF7V9l6

happens only in Firefox, Chrome and IE11 are fine

My investigation shows it regards 3 things:
1) JavaScript clock is running
2) this css selector: div.dgAbsoluteSymbol > div
3) input[type=number]

in firefox 46, turning off input[type=number] button arrows with -moz-appearance = textfield, removing it from stage or change type to text helped to workarround the issue. Today I see it's updated to Firefox 47 and this trick doesn't work for me anymore.

Thanks!



Actual results:

relayout process is visible, site blinks


Expected results:

no layout reaction expected, site should stay where it is

Comment 1

[Loic]

Is it possible to provide a reduced testcase with less CSS, SVG etc? (on http://codepen.io/ eg)

Comment 2

[Loic]

Regression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=11c3335d77fb751128c456daa204385d69678484&tochange=4de1094b41b27db10a5b0e5683ba4272c505ee9c

Regressed by Bug 1255968, I guess.

Comment 3

[Alice0775 White]

Attachment: remove svg and use textContent instead innerHTML

At least, I can reproduce the problem on Firefox22 (without e10s)

Comment 4

[Alice0775 White]

Setting layout.interruptible-reflow.enabled = false seems fix the problem.

And, I think Bug 1255968 expose the existing bug of interruptible-reflow.

Comment 5

[Alice0775 White]

Attachment: semi-reduced (reproduced on 45esr , Nightly50.0a1)

Comment 6

[Adrian Florinescu [:aflorinescu]]

Due to the fact that the testcase has been provided updating the keywords.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Well.  Interruptible reflow works like this: If the reflow takes too long we interrupt and paint as-is.  That's the whole point of interruptible reflow.

So the possible bugs here are:

1)  We should not be reflowing at all.  Not the case, since the clock
    is running, changing the DOM, needs relayout.
2)  The layout should not take long enough for interruptible reflow to kick in.
    Interrupts never happen within the first 100ms of a reflow.  I just checked,
    and on my hardware a full relayout of the comment 0 testcase, complete with
    box tree construction, etc, takes ~100ms.  But the time taken for the
    clock running should be a good bit smaller, I would think.  On the testcase
    in comment 3, a full relayout takes ~50ms over here, well under the 100ms
    threshold.  Note that I don't see the flashing on either testcase, on Mac.

The video is showing us basically making no progress on the reflow in 100ms or so, which is quite odd...

Just to check, does running with the GECKO_REFLOW_MIN_NOINTERRUPT_DURATION environment variable set to a larger value than 100 (1000, say) help?  How long does the relayout of this page take for you?

Comment 8

[Alice0775 White]

Tested on Nightly50.0a1 32bit e10s, Windows7 64bit with testcase of comment#0

GECKO_REFLOW_MIN_NOINTERRUPT_DURATION=2000 : reproduce
GECKO_REFLOW_MIN_NOINTERRUPT_DURATION=2500 : not reproduce

Comment 9

[Boris Zbarsky [:bzbarsky]]

Huh.  Does a full relayout of that page really take over 2000ms on your hardware?  Try this, in the console:

  var b = document.body; var s = b.style; s.display = "none"; b.offsetWidth; var start = new Date; s.display = ""; b.offsetWidth; console.log(new Date - start);

Comment 10

[Alice0775 White]

tested 3 times

1131
1141
1125

Comment 11

[Boris Zbarsky [:bzbarsky]]

That's really weird.  Why would you ever interrupt with a nointerrupt duration of 2000, then???

Comment 12

[Alice0775 White]

(In reply to Boris Zbarsky [:bz] (Out June 25-July 6) from comment #11)
> That's really weird.  Why would you ever interrupt with a nointerrupt
> duration of 2000, then???

Probably, The CPU was busy due to another application (running 7-zip in background) when I test comment#8. 

Retest(without other application):
GECKO_REFLOW_MIN_NOINTERRUPT_DURATION=1000 : reproduce
GECKO_REFLOW_MIN_NOINTERRUPT_DURATION=1500 : not reproduce

Sorry for the confusion.

Comment 13

[Boris Zbarsky [:bzbarsky]]

OK, so that makes more sense.   I'm still not sure why I'm not seeing this (on Mac).  Certainly mouse move events are considered input events that should interrupt layout on Mac...

Comment 14

[Boris Zbarsky [:bzbarsky]]

OK, so another performance test that might be relevant.  Try this on the first testcase in this bug:

  var d = document.getElementById("clockDiv"); d.offsetWidth; var start = new Date; d.textContent = "hello"; d.offsetWidth; console.log(new Date - start);

what gets logged?  I'm seeing numbers on the order of 30ms here.

Comment 15

[Alice0775 White]

(In reply to Boris Zbarsky [:bz] (Out June 25-July 6) from comment #14)
> OK, so another performance test that might be relevant.  Try this on the
> first testcase in this bug:
> 
>   var d = document.getElementById("clockDiv"); d.offsetWidth; var start =
> new Date; d.textContent = "hello"; d.offsetWidth; console.log(new Date -
> start);
> 
> what gets logged?  I'm seeing numbers on the order of 30ms here.

308
304
324

Comment 16

[Boris Zbarsky [:bzbarsky]]

OK, I guess that's consistently 10x slower than my numbers.  But that seems like a really suspiciously big performance difference to me...

Comment 17

[Alice0775 White]

(In reply to Boris Zbarsky [:bz] (Out June 25-July 6) from comment #16)
> OK, I guess that's consistently 10x slower than my numbers.  But that seems
> like a really suspiciously big performance difference to me...

Yep,  My PC is 7years old. Core2Quad Q8300(2.5GHz, 2.0GHz in power save mode) + 8MB RAM + AMD HD6450

Comment 18

[Alice0775 White]

s/8MB RAM/8GB RAM/

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.