Closed
Bug 1292521
Opened 9 years ago
Closed 8 years ago
Keyboard input performance regressed
Categories
(Core :: General, defect, P1)
Tracking
()
RESOLVED
DUPLICATE
of bug 1295214
Tracking | Status | |
---|---|---|
e10s | ? | --- |
firefox49 | --- | unaffected |
firefox50 | --- | ? |
firefox51 | --- | fixed |
People
(Reporter: jimm, Unassigned)
Details
(Keywords: qawanted, regression, Whiteboard: [gfx-noted])
STR:
Type in any text input or text area
Note how slow the characters display.
This is a recent (1-3 days) regression in Nightly.
Windows 7, 51.0a1 (2016-08-04)
![]() |
Reporter | |
Comment 1•9 years ago
|
||
seems to have gone away.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Whiteboard: asdfasdaddasaasdasdadsasda
![]() |
Reporter | |
Updated•9 years ago
|
Status: RESOLVED → REOPENED
tracking-e10s:
--- → ?
Resolution: WORKSFORME → ---
Whiteboard: asdfasdaddasaasdasdadsasda
![]() |
Reporter | |
Comment 2•9 years ago
|
||
Definitely back again, and blassey mentioned he's seeing it as well. This should block. Requires e10s to reproduce. May be related to work touch carets work and bug 1195722.
![]() |
Reporter | |
Comment 3•9 years ago
|
||
kats, any chance your touch work caused this?
Flags: needinfo?(bugmail)
![]() |
Reporter | |
Updated•9 years ago
|
Keywords: regression
Comment 4•8 years ago
|
||
Is this specific to touchscreens? Specific to Windows? (Typing speeds seems normal on my Linux touchscreen.)
![]() |
Reporter | |
Comment 5•8 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #4)
> Is this specific to touchscreens? Specific to Windows? (Typing speeds seems
> normal on my Linux touchscreen.)
Any standard workstation. I'm seeing it on win7. Input start off ok but after a while keyboard input into any text edit becomes laggy.
Typing this comment triggered it.
Comment 6•8 years ago
|
||
I can repro on a touchscreen Windows laptop, but not on a !touchscreen. Also, on the touchscreen, the problem goes away when dom.w3c_touch_events.enabled is set to 0.
==> The problem definitely seems related to recent touch work
Comment 7•8 years ago
|
||
Hmm, do you happen to have apz.drag.enabled set? If so, does disabling it resolve the problem?
Flags: needinfo?(jmathies)
Comment 8•8 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #3)
> kats, any chance your touch work caused this?
It's possible. Does disabling the accessible caret (layout.accessiblecaret.enabled_on_touch = false) fix it? If not, can you get a regression window?
Flags: needinfo?(bugmail)
Park in APZ until we figure out otherwise.
Component: General → Panning and Zooming
Version: Trunk → 51 Branch
Comment 10•8 years ago
|
||
I was unable to reproduce this on my Windows touchscreen device using the latest Nightly, with or without apz.drag.enabled. I had e10s force-enabled and all the other relevant prefs (APZ, touch events, caret) set to their nightly default values.
Updated•8 years ago
|
![]() |
Reporter | |
Comment 11•8 years ago
|
||
I'm getting this on a win7 system without touch. Disabling "smooth scrolling" in advanced prefs appears to fix the problem.
I'll test these other prefs and post back.
Also, this isn't keyboard specific, it slows down mouse event handling as well. I see slow double-click select handling in text inputs, and slow hover highlight handling too.
Flags: needinfo?(jmathies)
![]() |
Reporter | |
Comment 12•8 years ago
|
||
dom.w3c_touch_events.enabled - 0/2 - no impact.
layout.accessiblecaret.enabled_on_to=false seems to fix it.
Using this test case:
http://www.mathies.com/mozilla/forms.html
Fill a single line scrolling input with gibberish, then backspace to delete what was typed. Repeat a few times to trigger - after a bit text input / backspacing starts to lag.
![]() |
Reporter | |
Comment 13•8 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #12)
> dom.w3c_touch_events.enabled - 0/2 - no impact.
>
> layout.accessiblecaret.enabled_on_to=false seems to fix it.
>
Cancel this. I've had this off for a bit and I just ran into the pag again on a bugzilla bug.
![]() |
Reporter | |
Comment 14•8 years ago
|
||
s/pag/lag
![]() |
Reporter | |
Comment 15•8 years ago
|
||
I haven't found a setting yet that alters this behavior. It's hard to track down because it isn't reproducible when the browser starts up.. I was also unable to reproduce in a mozregression session.
Comment 16•8 years ago
|
||
In that case, can you try to get a gecko profile when it does occur? Maybe that will shed some light on what's causing the slowness.
![]() |
Reporter | |
Comment 18•8 years ago
|
||
Here's a profile with me sitting on a trello page trying to add a comment to a card. Every keystroke takes about a second to display.
https://cleopatra.io/#report=03e6c050f5e013d6e9cbfc495f9e842213d2a4c4&selection=0,1,2,3,4,5,6,7,8,9,10,11,12,13,445,446
Flags: needinfo?(jmathies)
![]() |
Reporter | |
Comment 19•8 years ago
|
||
The browser seems to be spending a lot of time in WaitForMessage. I wonder if bug 1072752 or bug 1273635 have something to do with this.
![]() |
Reporter | |
Comment 20•8 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #19)
> The browser seems to be spending a lot of time in WaitForMessage. I wonder
> if bug 1072752 or bug 1273635 have something to do with this.
Definitely not bug 1072752, that landed back in 2014.
![]() |
Reporter | |
Comment 21•8 years ago
|
||
Let's wait and see if the follow up in bug 1273635 fixes this in tomorrow's nightly.
![]() |
Reporter | |
Comment 22•8 years ago
|
||
appears to be fixed now.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 8 years ago
Resolution: --- → WORKSFORME
![]() |
Reporter | |
Comment 24•8 years ago
|
||
Still not fixed.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 25•8 years ago
|
||
So based on the jimm's comments so far it doesn't appear to be related to touch stuff. The profile from comment 18 also doesn't seem to be very useful, although it shows a surprising thing - display list times are in the multiple-hundreds-of-ms. But the main thread stack during those display list builds shows the the thread just waiting for messages, with no display list building activity on the stack. So I have no idea what that's all about.
Throwing this back into untriaged since I don't think we have any real leads on what's going on, and seem to have eliminated recent APZ/touch work at least.
Component: Panning and Zooming → Untriaged
![]() |
Reporter | |
Comment 26•8 years ago
|
||
I'm currently running a long mozregression session on this, hope to nail down a good range over the next few hours.
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment hidden (offtopic) |
![]() |
Reporter | |
Comment 30•8 years ago
|
||
I've reconfirmed this range twice now. I think I've nailed it down. Will confirm again to be sure.
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=dcae241857b185f583f6c3f568b1bd3b1b52de41&tochange=5935d93680fc53f823d29a8f97b06290cdd019f5
![]() |
Reporter | |
Updated•8 years ago
|
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → DUPLICATE
Comment 32•8 years ago
|
||
This was fixed in bug 1295214
Comment 33•7 years ago
|
||
Moving from Core::Untriaged to Core::General https://bugzilla.mozilla.org/show_bug.cgi?id=1407598
Component: Untriaged → General
You need to log in
before you can comment on or make changes to this bug.
Description
•