Closed Bug 1292521 Opened 8 years ago Closed 8 years ago

Keyboard input performance regressed

Categories

(Core :: General, defect, P1)

Product:
Core
Component:
General
Version:
51 Branch
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1295214
Tracking Flags:
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)
seems to have gone away.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Whiteboard: asdfasdaddasaasdasdadsasda
Status: RESOLVED → REOPENED
tracking-e10s: --- → ?
Resolution: WORKSFORME → ---
Whiteboard: asdfasdaddasaasdasdadsasda
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.
kats, any chance your touch work caused this?
Flags: needinfo?(bugmail)
Keywords: regression
Is this specific to touchscreens? Specific to Windows? (Typing speeds seems normal on my Linux touchscreen.)
(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.
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
Hmm, do you happen to have apz.drag.enabled set? If so, does disabling it resolve the problem?
Flags: needinfo?(jmathies)
(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
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.
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)
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.
(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.
s/pag/lag
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.
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.
^
Flags: needinfo?(jmathies)
Whiteboard: [gfx-noted]
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)
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.
(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.
Let's wait and see if the follow up in bug 1273635 fixes this in tomorrow's nightly.
appears to be fixed now.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → WORKSFORME
Still not fixed.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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
I'm currently running a long mozregression session on this, hope to nail down a good range over the next few hours.
Depends on: 1295214
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → DUPLICATE
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.