Firefox performs relayout on mouse move causing site blinking

NEW
Unassigned

Status

()

Core
Layout
2 years ago
2 years ago

People

(Reporter: a.sergeev, Unassigned, NeedInfo)

Tracking

({testcase})

47 Branch
x86_64
Windows 7
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

2 years ago
Created attachment 8761319 [details]
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
(Reporter)

Updated

2 years ago
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64

Comment 1

2 years ago
Is it possible to provide a reduced testcase with less CSS, SVG etc? (on http://codepen.io/ eg)
Flags: needinfo?(a.sergeev)
Keywords: testcase-wanted

Comment 2

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

Regressed by Bug 1255968, I guess.
Status: UNCONFIRMED → NEW
Component: Untriaged → Layout
Ever confirmed: true
Flags: needinfo?(alice0775)
Product: Firefox → Core

Comment 3

2 years ago
Created attachment 8762129 [details]
remove svg and use textContent instead innerHTML

At least, I can reproduce the problem on Firefox22 (without e10s)
Flags: needinfo?(alice0775)

Comment 4

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

And, I think Bug 1255968 expose the existing bug of interruptible-reflow.
Blocks: 67752
Flags: needinfo?(bzbarsky)

Comment 5

2 years ago
Created attachment 8762149 [details]
semi-reduced (reproduced on 45esr , Nightly50.0a1)
Due to the fact that the testcase has been provided updating the keywords.
Keywords: testcase-wanted → testcase
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?
Flags: needinfo?(bzbarsky)

Comment 8

2 years ago
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
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

2 years ago
tested 3 times

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

Comment 12

2 years ago
(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.
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...
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

2 years ago
(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
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

2 years ago
(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

2 years ago
s/8MB RAM/8GB RAM/
You need to log in before you can comment on or make changes to this bug.