1276896 - Firefox 46 find toolbar & text field input event ordering regression

Status: RESOLVED INCOMPLETE

(Toolkit :: Find Toolbar, defect)

Description

[simon]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160511224433

Steps to reproduce:

Pressing `/` to search in-page is not always instantaneous, especially if done while the page is running a lot of js. This is fine and expected. The problem comes when pressing / and immediately starting to type (e.g. 'hello') in a situation where the search bar takes a bit of time to open.

Firefox 46.0.1, running on xubuntu 14.04. Issue is new to FF46; 45 and earlier worked correctly.


Actual results:

Keys pressed subsequent to `/` but before the search bar actually opens are sent to the page you have open. This is a problem if using a webapp which has a lot of keyboard shortcuts (e.g. google Inbox), or if (like me) you use VimFX to make most browser actions accessible by keyboard shortcut (some of which are destructive).

(It's not limited to the search bar: I've also experienced several times (with FF46 only) clicking on a text field to select it, while the page was still loading (which visually changed it to a selected text field, including blinking cursor), but typing still sent the characters to the page window).


Expected results:

The behaviour in Firefox 45 or earlier: event ordering is preserved. Keys pressed subsequent to `/` would show up in the search bar once it has loaded.

(Alternative acceptable behaviour would be for keystrokes to just disappear while the search bar is loading. While mildly inconvenient, that's still a lot better than them going to the page, where they might cause destructive actions).

Comment 1

[Loic]

Example of page to test the issue?

Comment 2

[simon]

> Example of page to test the issue?

It's not a page-specific issue. But can reproduce the problem more easily with a js-heavy page (facebook, cnn.com, whatever) which is still loading or refreshing. It's even easier to reproduce if cpu is restricted eg in a spec-limited VM, or while running prime95 or something in the background with a nice value lower than firefox's)

Comment 3

[Loic]

I'm not able to reproduce the issue with FF46 on Win 7. Could you install mozregression to find a regression range, please.
See http://mozilla.github.io/mozregression/ for details.

You can run the command "mozregression --good=45" then copy the final pushlog.

Comment 4

[Firefox Bug Husbandry Bot]

2019-03-06

This bug is part of a group of bugs which have had an open needinfo for at least 12 weeks.

The request for information has not been answered, and we can't move forward on the bug so we are closing it.

If the defect is still present, please reopen this bug with an updated report.