Keyboard input performance regressed

RESOLVED DUPLICATE of bug 1295214

Status

()

Core
General
P1
normal
RESOLVED DUPLICATE of bug 1295214
2 years ago
7 months ago

People

(Reporter: jimm, Unassigned)

Tracking

({qawanted, regression})

51 Branch
qawanted, regression
Points:
---

Firefox Tracking Flags

(e10s?, firefox49 unaffected, firefox50 ?, firefox51 fixed)

Details

(Whiteboard: [gfx-noted])

(Reporter)

Description

2 years ago
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

2 years ago
seems to have gone away.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
Whiteboard: asdfasdaddasaasdasdadsasda
(Reporter)

Updated

2 years ago
Status: RESOLVED → REOPENED
tracking-e10s: --- → ?
Resolution: WORKSFORME → ---
Whiteboard: asdfasdaddasaasdasdadsasda
(Reporter)

Comment 2

2 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

2 years ago
kats, any chance your touch work caused this?
Flags: needinfo?(bugmail)
(Reporter)

Updated

2 years ago
Keywords: regression
Is this specific to touchscreens? Specific to Windows? (Typing speeds seems normal on my Linux touchscreen.)
(Reporter)

Comment 5

2 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.
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.
status-firefox49: --- → unaffected
status-firefox50: --- → ?
Priority: -- → P1
(Reporter)

Comment 11

2 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

2 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

2 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

2 years ago
s/pag/lag
(Reporter)

Comment 15

2 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.
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]
(Reporter)

Comment 18

2 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

2 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

2 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

2 years ago
Let's wait and see if the follow up in bug 1273635 fixes this in tomorrow's nightly.
(Reporter)

Comment 22

2 years ago
appears to be fixed now.
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago2 years ago
Resolution: --- → WORKSFORME
(Reporter)

Updated

2 years ago
Duplicate of this bug: 1294968
(Reporter)

Comment 24

2 years ago
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
(Reporter)

Comment 26

2 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

2 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

2 years ago
Depends on: 1295214
(Reporter)

Updated

2 years ago
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1295214
No longer depends on: 1295214
This was fixed in bug 1295214
status-firefox51: affected → fixed
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.