Closed Bug 1731165 Opened 4 months ago Closed 4 months ago

Typing multiple spaces on an empty input element is slow/unresponsive

Categories

(Core :: Layout, defect, P2)

Firefox 92
Unspecified
All
defect

Tracking

()

VERIFIED FIXED
95 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- unaffected
firefox92 --- wontfix
firefox93 --- wontfix
firefox94 --- wontfix
firefox95 --- verified

People

(Reporter: robert, Assigned: emilio)

References

(Regression, )

Details

(Keywords: perf, regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

1- Open a web page with an input element, like the MDN input example:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input

or any input element inside the Firefox UI (the dedicated search field on the toolbar)

2- Focus on the input element and type spaces multiple times, fast, or let the key pressed in order to repeat the spaces.
3- Empty the field and now type a letter and the repeat typing multiple spaces

Actual results:

When the input field is empty at step 2, spaces added slowly, like an unresponsive UI busy processing events.

At step 3, when the field contents start with a letter, spaces are added fast as expected

Expected results:

Step 2 and 3 should be both responsive and fast.

Tested with and version 90 Firefox developer edition build I still haven't updated and the space typing speed was fine. With Firefox 92, is slow even on a new empty profile. It looks like a regression from 90 or 91.

Component: Untriaged → Performance
Product: Firefox → Core

I can reproduce the issue on Nightly94.0a1 Windows10.
Keep holding keydown `Space Bar' does not update caret position smoothly.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f6410b337e8aa34545ae5545ec7b49d1aa706e5d&tochange=ccc6e271d9dbd7bbb3b0c640ff267cb6120322a9

Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
Component: Performance → Layout
Ever confirmed: true
Keywords: perf, regression
OS: Unspecified → All
Regressed by: 1663475

Well, it's not a perf thing. It's not "slow" as in using a lot of CPU, it seems we're just not repainting the caret properly. Will look, thanks!

Flags: needinfo?(emilio)
Assignee: nobody → emilio
Flags: needinfo?(emilio)

Not sure how easy it is to come up with a test-case for this, will try
though.

Changing severity to S3 because it's a small-ish issue, and an old regression.

Severity: -- → S3
Priority: -- → P2
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/340719f2946c
Invalidate the right frame from nsCaret::SchedulePaint when we paint the caret from the containing block. r=miko
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 95 Branch

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(emilio)
Flags: needinfo?(emilio)
Flags: qe-verify+

Reproduced this on macOS 10.15 on an affected Nightly build 95.0a1 (20210916094303) following the steps from comment 0.

Verified as fixed on Beta 95.0b2 (20211102190739), across following platforms: Win 10x64, macOS 10.15 and Ubuntu 20.04. Space typing response time is correct.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Duplicate of this bug: 1737452
You need to log in before you can comment on or make changes to this bug.