1240632 - [e10s] Several async animations (OMTA) at once don't finish at the same moment (lag separately)

Status: RESOLVED DUPLICATE of bug 1301305

(Core :: DOM: Animation, defect, P4)

Description

[arni2033]

Attachment: testcase 1 - OMTA lag separately.html

>>>   My Info:   Win7_64, Nightly 46, 32bit, ID 20160116030240
See screencasts first. Also, I'm not sure it only happens in e10s mode.
> screencast 1 (STR_1):   https://dl.dropboxusercontent.com/s/r27rw7ts6dttxv9/STR_1.webm?dl=0
> screencast 2 (STR_2):   https://dl.dropboxusercontent.com/s/zbf4sfbrbkozz30/STR_2.webm?dl=0

STR_1:
1. Open http://www.youtube.com/watch?v=SGP6Y0Pnhe4, make sure that autoplay is enabled
2. Open any 5 other youtube videos in new tabs, mute that tabs
3. Open Console (Ctrl+Shift+K), type there «document.querySelector(".ytp-settings-button").click();»
   without outer quotes, press Enter
4. Focus the search field "Search HTML", type there
   "#ytp-main-menu-id > .ytp-menuitem:first-child" without quotes, press Enter
5. In the focused node, replace attribute value from [aria-checked="true"] to [aria-checked="false"]
6. (optional) for each tab opened in Step 2: right-click that tab and click "Reload tab"
7. Click on the focused node in Inspector to make sure it's focused
8. Repeat this several times: {press Ctrl+Z, then Ctrl+Y}

STR_2:
1. Open http://www.youtube.com/watch?v=SGP6Y0Pnhe4, mute the tab
2. Open attached testcase, maximize the firefox window
3. Detach the tab opened in Step 1 into separate window, dock it to the right side of screen
4. Start constantly resizing the window opened in Step 3.

STR_3:
1. Open http://www.youtube.com/watch?v=SGP6Y0Pnhe4, mute the tab
2. Open attached testcase
3. Right-click the tab opened in Step 1, click "Reload tab"
4. (optional) repeat Step 3.

AR:  Sometimes the white circle appears at the right side of "checkbox",
       but the background is dark red/gray, not bright red.
     Sometimes the white circle appears at the left  side of "checkbox",
       but the background is bright red/dark red, not gray.
       
ER:  When the white circle appears at the right side of "checkbox", background should be bright red.
     When the white circle appears at the left  side of "checkbox", background should be gray.

     Because all CSS duration is the same for all transitions (0.5s)
     That means that they should be finished at the same time no matter what.
     When I set layers.offmainthreadcomposition.async-animations -> true, it works as expected
     
Notes: 
 I have a suspicion that it _is_ working "as expected", but in this case this
 should be confirmed by somebody working on async animation (because, agree that this looks weird).

Comment 1

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

Thanks for the excellent bug report!

I can't reproduce with e10s turned on or off on Windows 10 but I suspect that's because I'm on a more powerful (or simply less busy) machine.

It looks like we have three transitions: one background-color transition on the <div> and one transform transition on each of the pseudos (::before for the tick and ::after for the circle). The transform transitions run on the compositor but the background-color transition runs on the main thread. Hence, when the machine is under load (as it appears to be in the video) we can get a situation where the transform transitions finish noticeably before the background-color transition finishes.

I'm not sure what else we can do here. I think long-term we may end up introducing a way for authors to opt-out of compositor animations or, more likely, indicate that a set of animations have their rendering synchronized so that if one component cannot be run on the compositor thread, none of them will be.

(Incidentally, this will be a lot easier to debug once we fix bug 1174575 since you would be able to see the three transitions in the Animations panel and see that two of them are running on the compositor.)

Comment 2

[Kanchan Kumari QA]

Thank You Arni2033 for writing such a clear and detailed bug report! 

When I tried duplicating it on my Windows 7 64 bit system with a powerful processor (Intel Core I7-4810MQ @2.8 GHz) and memory (16 GB), I was not able to duplicate the issue at all on the latest nightly build (47.0a1).

However by reading the steps, it was evident that it might had to do something with how busy the system is or how much resource is available to Firefox for such an operation. 

I created a Windows 7 Virtual Machine with lesser resources and then I was able to duplicate the issue every time. In fact, when I tried re-sizing the window several times, Firefox crashed twice. I have submitted one of the crash reports. URL is https://crash-stats.mozilla.com/report/index/f57b2791-8d28-42bd-9865-503262160207.

Our developers will look into it based on the priority and criticality of this defect. Once again, thank you for writing such a wonderful bug report!

Comment 3

[arni2033]

>>>   My Info:   Win7_64, Nightly 52, 32bit, ID 20161011030212 (2016-10-11)
Youtube changed something in checkbox, and now I don't see this bug on Youtube. Also, I don't think I can reproduce any of scenarios 1-3, which is strange. STR_4 is most reliable currently.

STR_4:
0. It's better to open ~10-20 tabs with site http://www.rp-online.de/ in background ("real-life UX")
1. Open url [1], scroll down by 1 screen
2. Keep clicking on hamburger button on the site (element "#menu-trigger") for ~10 seconds

AR:  The top line inside that button is usually animated nice, the other two lag.
ER:  All 3 lines should move / change opacity synchronously, just like it was before OMTC

> [1] http://www.muscleandfitness.com/athletes-celebrities/news/obese-beast-guy-bravely-strips-down-show-what-extreme-weight-loss-does?utm_source=outbrain2&utm_medium=cpc
> screencast 3 (STR_4):   https://dl.dropboxusercontent.com/s/ehxfgcrhm63kewj/STR_4.webm?dl=0

Notes:
1) Setting pref "layers.offmainthreadcomposition.async-animations" to false fixes STR_4
2) Or are you telling me that web developers should regularly check "Animations" tab in inspector and
   avoid situations when some parts of animation runs on compositor, and others do not? Sounds like a
   new level of complexity. I expect something more like pref "apz.disable_for_scroll_linked_effects",
   enabled by default, that would run some/all animations NOT on compositor, avoiding this bug.

Comment 4

[Hiroyuki Ikezoe (:hiro)]

I guess one of the reasons is bug 1208411.  Several animations both on the main-thread and the compositor run more synchronous than before.  But yes, this problem still exists.

Comment 5

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

I think this will be fixed by bug 1301305 which I plan to work on soon. Or at least, I plan to implement the idea in bug 1301305 comment 8 and bug 1301305 comment 10 and then do some data gathering to try and determine if it has a net positive impact or not (it's possible it might regress the performance of some content).

Comment 6

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

So I confirmed that the optimization in bug 1301305 fixes this but I'm actually looking at reverting that in bug 1540906 so I'll need to be careful not to break this again there.