1292722 - Laggy keyboard and mouse since 2016-07-30 build

Status: VERIFIED DUPLICATE of bug 1295214

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Gordon Cowie]

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20160805030444

Steps to reproduce:

I can reproduce this as of 51.0a1 (2016-08-05) on a fresh profile but I originally noticed right after the update on 2016-07-30. These steps are simplest:
1) add some bookmarks menu to your toolbar (this isn't necessary to cause the issue - just this is the easiest way to demonstrate the symptoms)
2) start two instances of Firefox
3) in the first instance open the js console and start an infinite loop "while(true) { console.log("test") } - optionally you can load some js heavy page or start any html5 video player
4) in the 2nd instance, interact with the bookmark menu and observe 2-3+ second delays for the UI to react to mouse events

I took a couple of screen captures as well:
http://imgur.com/gallery/6lns1

The bookmark menu lag is one symptom. If you open a page with a textarea and try to type in it you will notice similar lag with keyboard input.

Comment 1

[SimonP]

Confirming that this bug also affects Aurora since the first 50.0a2 build. The problem leads to general UI and renderer sluggishness. It's possible only x64 builds are affected, but I haven't confirmed this yet.

Comment 2

[Vlad Bacia-Mociran [:VladB]]

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20160809030200

I have tested your issue on latest Nightly (v51.0a1) and managed to reproduce it. In a tab from the first browser window I have "http://www.sbs.com.au/theboat/" and in the console I've started the infinite loop. In the second browser the lag is barely noticeable, but it's still there. e10s was enable during testing. See also bug 1240704.

Comment 3

[SimonP]

I attempted disabling e10s, and the problem persisted, so it does not appear to be e10s-related. 

User Agent is: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20160810004000

Comment 4

[SimonP]

Aurora regression window:

"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0" - "20160731004003" - Unaffected
"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0" - "20160801004002" - Unaffected
"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0" - "20160801085519" - Affected

Comment 5

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi John, would you please help check comment 4 and see if we could get more profiling data? Thanks!

Comment 6

[Hsin-Yi Tsai (she/her) [:hsinyi]]

I followed comment 2 and tried different versions mentioned in comment 4. I observed slightly lag but seems the lag difference from every version wasn't really obvious, it's hard for me to say that my observation 100% aligns with the range in comment 4. I also tested on a nightly build for 2016-07-01 and I felt the lag, too... So, it's not confirmed by me that it's a regression and I'm going to remove the keyword for now.

@SimonP, it would be great if you could provide a simple test case that eases to reproduce your observation on comment 4. Any more profiling data would be useful as well. Thank you very much.

We might need to come up with some ideas clarifying this issue first. However, before the root cause is confirmed, it's hard to say the priority, so using P3 + "perf" keyword for tracking this kinda issue.

Comment 7

[Gordon Cowie]

I think the lag that is reproducible with the just the infinite loop is mild and may have been reproducible since before 2016-07-30. If instead of the infinite loop you load a js heavy site (facebook and reddit with several embedded video players seems to do the trick here) you notice the keyboard and mouse lag gets much, much worse. It also seems to get worse with time. The severity of the symptoms goes from tolerable to unusable between 2016-07-28 and 2016-08-01.

Comment 8

[SimonP]

My observations are in line with gcowie's. The best way to reproduce is to play multiple videos at once. In my case, UI unresponsiveness becomes apparent within minutes as a couple hundred milisecond delay. It takes over an hour for the browser to become unusable (input latency over a second), and unfortunately I have no reliable way of reproducing this quickly.

Comment 9

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi gcowie and SimonP, 
would you please get a profile for a good and bad build by following the article? 
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem

Comment 10

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

This bug is probably a duplicate of bug #1295214.
Please retest to see if it's fixed in latest Nightly (51.0a1 [2016-08-27]),
if not, reopen this bug.

Comment 11

[Gordon Cowie]

Confirming the UI performance with heavy js/video is back on par with the 2016-07-28 build, thank you!

Starting an infinite loop in the console will still bring all instances to their knees but that is reproducible on the 2016-07-28 as well. I'll try to find or open another bug for that.

Comment 12

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Thank you :Virtual and gcowie for the verification.