1251751 - Parts of input field and button blink with black color when I reload https://ya.ru/

Status: NEW

(Core :: Layout, defect)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 47, 32bit, ID 20160225030209
STR:
1. Open https://ya.ru/
2. Keep pressing F5 for 10 seconds at the speed ~1 pressings per second

AR:  Parts of input field and button blink with black color
ER:  All yellow area should be yellow from the start. No blinking

This is regression between 2015-01-05 and 2015-01-06. (regressionwindow-wanted)
> https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=636498d041b5&tochange=2a193b7f395c

Notes:
1) This doesn't happen in GoogleChrome
2) This may happen because page loading became... more sluggish? I'm not sure.
3) I don't know if this is really a Firefox issue, but it looks like one.
4) This is ~50% reproducible on e10s and  100% reproducible on non-e10s.
   I found the regression window using prefs to disable e10s completely (including old prefs).

Comment 1

[arni2033]

Screencast in multiprocess mode:
> https://dl.dropboxusercontent.com/s/i05sq475u00b8f8/screencast%201%20-%20Parts%20of%20input%20field%20and%20button%20blink%20with%20black%20color.webm?dl=0

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

Could you give us the graphics section of about:support of the compute that reproduces this problem?

Comment 3

[arni2033]

(In reply to Milan Sreckovic [:milan] from comment #2)
> Could you give us the graphics section of about:support?
attachment 8716578 [details]

Comment 4

[Hiroyuki Ikezoe (:hiro)]

Attachment: Reduced and more noticeable example HTML

I think this behavior is correct.
To reproduce this behavior we need an external CSS file containing CSS transition of background-color.  I will attach it here later.

Comment 5

[Hiroyuki Ikezoe (:hiro)]

Attachment: The external CSS file

Comment 6

[Hiroyuki Ikezoe (:hiro)]

When reloading the HTML (attachment 8733749 [details]):

1) Loaded HTML
2) Run the script in HTML
3) invoked a.offsetHeight (this leads layout flush)
4) painted the background of the span element in HTML
5) parsed (or loaded? I am not sure) the external CSS 
6) set the new background color of the span element
7) started transition

That's all!

Comment 7

[arni2033]

Attachment: bug 1251751 testcase 1 (95 percent).htm

Comment 8

[arni2033]

Attachment: bug 1251751 testcase 2 (5 percent).htm

Comment 9

[arni2033]

Attachment: bug 1251751 testcase 3 (1 percent).htm

Comment 10

[arni2033]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #6)
So, this bug was not visible, on https://ya.ru/ because transition didn't work inside button with
overflow:hidden. It was fixed in bug 927349, and exposed this underlying issue.

I'm not sure that it's expected, because people normally use animations to get the same effect,
not transitions. I explained my point below.

1) The same effect (transition from irrelevant color to expected color) could be observed if I add
   some other stylesheet before the script. In original example, user agent stylesheet serves the
   same purpose (instead of additional stylesheet mentioned above)

2) First of all, that's not expected way for transitions to work. Right now they basically take
   into account the value set by previous stylesheet. That's not expected during loading, because
   Stylesheets may be loaded at different time, and that makes final result unpredictable.

3) What does the Spec say about that explicitly? Different behavior depending on whether a script
   used offsetHeight or not - looks like a trap. Other browsers (IE11, GoogleChrome) don't do that.

4) Even if animation instead of transition is expected result, it doesn't work with "testcase 2" and
  "testcase 3", at least locally. So anyway Firefox's the only browser that does this inconsistently

Testcase 1 - 95% bug  (reproducible in 95% of cases)
Testcase 2 -  5% bug  (reproducible in 5% of cases)
Testcase 3 -  1% bug  (reproducible in 1% of cases)

I checked old versions using "testcase 1", and it appears that this behavior was added in 2 steps
Before (1)      -  1% reproducible
Between (1),(2) - 10% reproducible
After (2)       - 95% reproducible
>(1) https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4dfe323a663d&tochange=634180132e68
>(2) https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b836d89be72b&tochange=0e91262606a6

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

Sounds like there is a bit of a race condition, so the regression ranges from the previous comment may not help us - that could be just something speeding things up in some parts and changing the overall timing.

Brian, can you comment on the #3 spec question from comment 10?  If not you, who could?

Comment 12

[Brian Birtles (:birtles, Feb 26~ parental leave)]

(In reply to arni2033 from comment #10)
> 3) What does the Spec say about that explicitly? Different behavior
> depending on whether a script
>    used offsetHeight or not - looks like a trap. Other browsers (IE11,
> GoogleChrome) don't do that.

The relevant part of the spec is:

  https://drafts.csswg.org/css-transitions/#starting

Specifically,

  "This processing of a set of simultaneous style changes is called a style change event. (Implementations typically have a style change event to correspond with their desired screen refresh rate, and when up-to-date computed style or layout information is needed for a script API that depends on it.)"

Here, calling offsetHeight triggers a style change event. This is true in all browsers. And yes, it's a known trap with CSS transitions.

The spec doesn't say when these style changes occur, (it says, "This specification does not define when computed values are updated") but at least with regard to offsetHeight all browsers I'm aware of are consistent.

From a cursory glance at the bug description, it sounds like we might have a race condition related to stylesheet loading and presumably other browsers differ in the way they load external stylesheets.

Comment 13

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Platform triage comment: This is a regression since Fx46 (based on regression range).