Keyboard input is extremely laggy on twitter.com
Categories
(Core :: Layout: Flexbox, defect, P2)
Tracking
()
People
(Reporter: alice0775, Unassigned)
References
(Blocks 1 open bug, Regression)
Details
(4 keywords)
Attachments
(4 files)
This seems a recent regression.
Reproducible: often
Steps To Reproduce:
- Open https://twitter.com/home
- Keyboard input several character to "What's happening?"
e.g,. aaaa aa aaa aaaa aa aaa aaaa aa aaa aaaaa aa aaa
Actual Results:
Super laggy
Expected Results:
not laggy
Gecko Profiler log: https://perfht.ml/2A0RB86
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 3•5 years ago
|
||
Steps to reproduce:
- Open the attached reduced html
- Click just after "Click here "
- Keydown [Back Space] and keep hold until the field is emptied
- keydown [a] and keep hold until "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
- Repeat from step 3 (5-10times)
Actual Results:
Becomes super laggy
In the attached reduced testcase, at least two major regressions seem to be there.
#1, key input slowdown after repeat step3 5 times
#2, key input super laggy after repeat step3 more 3 times
#1 regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e07c0fe7189bd39dd52625006a29edbcac2e9750&tochange=c2141e08383873f70201cc84613ef5904cb27d07
#2 regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d7b5e712bf67506589579e37c162590064e5d950&tochange=c51ba76790c01fe9c00aa4a03ea2f6d3aa397286
Comment 4•5 years ago
|
||
Marking 70 as affected given the regression range, Mike could the patches in bug 1573566 have caused this regression?
Updated•5 years ago
|
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Comment 5•5 years ago
|
||
dholbert, could you take a look at the profile. There is some deep flexbox reflow happening.
regression ranges do look surprising.
Comment 6•5 years ago
|
||
This sounds a lot like bug 1527786, though we had trouble reproducing the bug there. (So far I haven't been able to reproduce here, either... just tried STR from comment 3 but didn't hit any lag. Perhaps I didn't repeat enough times.)
I'm backed up on requests right now but will hopefully get a chance to look at this within a couple days.
Updated•5 years ago
|
Comment 8•5 years ago
|
||
Given the profile shows this is happening in layout, let's move there at least for the time being.
Comment 9•5 years ago
|
||
Bug 1579502 presumably fixed #2.
#1 is unexpected... it would imply that LTO during PGO generate matters?!
Updated•5 years ago
|
Updated•5 years ago
|
Comment 10•5 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #9)
Bug 1579502 presumably fixed #2.
#1 is unexpected... it would imply that LTO during PGO generate matters?!
I guess if you're not PGO use'ing with the same settings that you're PGO generate'ing, that would eventually manifest as a problem? Did we have problems with doing LTO during PGO generate, or was that just done in the interest of trying to save time during builds?
Updated•5 years ago
|
Tracking, if you come up with a solution we could still take a patch in 70.
Andrei, can you help find someone to try and replicate this ? Thanks!
Comment 15•5 years ago
|
||
So, I tried reproducing this issue by STR from Comment 0 and Comment 3 respectively, but had no success.
On the other hand, the method I successfully was able to reproduce the lagginess can be seen in the screencast attached. Shortly, keep pressed A letter and fast right click two or three times over the letters. This will make Twitter get laggy and the second effect of this is that it will register the letters, but can't delete them by any means.
This was done on Windows 10 (x64) 1903, and on Nightly 71.0a1 (2019-09-06).
Please let me know if I can be of any help further.
Comment 16•5 years ago
|
||
Here is the attachment.
Comment 17•5 years ago
|
||
Given the difficulty of reproduction, I'm going to mark this fix-optional in 70. We will keep investigating for now.
Updated•5 years ago
|
Reporter | ||
Comment 18•5 years ago
|
||
Nightly72.0a1(20191104214406) hang up when delete input text.
https://perfht.ml/2WKbt9Z
Comment 19•5 years ago
|
||
This might be the same core issue as bug 1579929 - this could be a large interruptible reflow, which is getting interrupted by the user-input-event (the character press and/or delete), which then causes cached flex-item measurements to be purged which makes the rest of the reflow unintentionally expensive to complete as described in bug 1579929 comment 29.
Comment 20•5 years ago
|
||
Alice0775, would you mind testing to see if this is fixed in the latest Nightly?
I'm hoping that the same patches that fixed bug 1579929 will have fixed this, too.
[EDIT: sorry, I initially left out a digit in that bug number; I've edited the comment in-place to fix.]
Reporter | ||
Comment 21•5 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #20)
Alice0775, would you mind testing to see if this is fixed in the latest Nightly?
I'm hoping that the same patches that fixed bug 1579929 will have fixed this, too.
[EDIT: sorry, I initially left out a digit in that bug number; I've edited the comment in-place to fix.]
uum, I can still reproduce the issue on Nightly72.0a1 20191119043902. Keyboard input is super laggy.
(However, I cannot reproduce on Beta71.0b10.)
Reporter | ||
Comment 22•5 years ago
|
||
https://perfht.ml/332hLU3 on Nightly72.0a1 20191119043902
Comment 23•5 years ago
|
||
OK, thanks for checking (and for the profile). Looks like we've still got some slow real slow reflow-on-keypress in there (in the 100-500ms range).
Comment 24•5 years ago
|
||
Hmm, the slow reflow comes from ScrollSelectionIntoViewEvent... Is there any reason that has to run early in the refresh driver tick rather than later (where it wouldn't need to reflow again?)
Not sure if that'd win us anything though.
Updated•5 years ago
|
From comment 21, sounds like this may be a nightly-only problem now.
Comment 26•5 years ago
|
||
Hi Catalin, can you confirm that only Nightly is affected but not beta?
Comment 27•5 years ago
|
||
Hi Jens, I tried reproducing the issue but had no success both on Firefox 74.0b2 and Nightly 75.0a1 (2020-02-12) with all the steps from Comment 0, Comment 3 and Comment 15. It seems to be fixed.
Reporter | ||
Comment 28•5 years ago
|
||
Nightly 75.0a1(20200212205745) and Firefox 74.0b2 is still laggy than Firefox73.0 on Windows10.
Reporter | ||
Comment 29•5 years ago
|
||
STR
Disable spellchecker if any
Hold down "a" key
Screencast:
0:00-0:11 75.0a1
0:11-0:24 74.0b4
0:24- 73.0
Comment 30•5 years ago
|
||
Original case was an increasing laggyness while using the input box, which I assume is now fixed as of comment 27.
So what Alice sees here is probably a more general (but less extreme) regression?
Reporter | ||
Comment 31•5 years ago
|
||
Nightly75.0a1 https://perfht.ml/3byzY0P
Reporter | ||
Comment 32•5 years ago
|
||
(In reply to Jens Stutte [:jstutte] from comment #30)
Original case was an increasing laggyness while using the input box, which I assume is now fixed as of comment 27.
So what Alice sees here is probably a more general (but less extreme) regression?
Yes, it is laggy but not extreme(need patience:)
I don't know if this is another regression because I can't find another good builds after comment#3 bad build.
Comment 33•5 years ago
|
||
Thanks for your help, Alice, this helps hopefully to assess the severity.
Updated•5 years ago
|
Comment 34•5 years ago
|
||
We are going to keep investigating flexbox perf issues, but the likelihood that this will see improvement in 75 is pretty low. I'm going to update to reflect reality.
Reporter | ||
Comment 35•5 years ago
|
||
Tested on Nightly76.0a1(20200326213652), text input is much better than before.
I will mark this as WORKSFORME.
Updated•3 years ago
|
Updated•3 years ago
|
Description
•