1545896 - New window does not accept typing immediately

Status: RESOLVED WONTFIX

(Core :: DOM: UI Events & Focus Handling, defect, P5)

Description

[David Turner]

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

Steps to reproduce:

I'm running on Debian. I open a new window with Ctrl-N. Immediately, before the window fully vivifies, I start typing.

Actual results:

The text is eaten.

Expected results:

I expect that the text I type will appear in the Google search box (as my new window page is Google) once the window has finished loading. That's how it works on Chromium.

Comment 1

[Alin Ilea, Desktop QA]

Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0

Hi,

I have tested your issue on latest FF release (66.0.3) and latest Nightly build and could not reproduce it, using Ubuntu 18.04 and Debian.

I think your issue is related to add-ons, so if the issue is still reproducible on your end, can you please retest this using latest FF release and latest Nightly build (https://nightly.mozilla.org/) and report back the results? When doing this, please use a new clean Firefox profile (https://goo.gl/AWo6h8), maybe even safe mode (https://goo.gl/AR5o9d), to eliminate custom settings as a possible cause.

If the issue is no longer occurs with new clean profile, try to enable add-ons that are you using one by one until the problem appears again to find which add-on causes the problem.

Thank you for your report.

Comment 2

[David Turner]

I just tested this on Nightly with a fresh profile, no add-ons. It's maybe a little better (maybe -- I can't easily time it), but it's still not perfect. Have you tried typing faster? Just press ctrl-n and immediately start typing. The first few characters are still lost. Same with Safe Mode.

Comment 3

[Alin Ilea, Desktop QA]

Hi,

Yes, I've tried to type faster after the page is opened with ctrl-n but I still cannot reproduce the issue.

I'm going to set a component so developers can take a look at it. If this is not the right component, please feel free to move it to a more appropriate one.

Thanks for collaboration.

Comment 4

[Henri Sivonen (:hsivonen)]

I can't reproduce the problem, because the computer I'm using opens windows so fast. However, if we were to treat this as a bug, I'd expect the events to queue up on the widget level--not on the editor level.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Moving all keyboard/IME open bugs to DOM: UI Events & Focus Handling component.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Henri Sivonen (:hsivonen) from comment #4)

I can't reproduce the problem, because the computer I'm using opens windows so fast. However, if we were to treat this as a bug, I'd expect the events to queue up on the widget level--not on the editor level.

Yeah, I agree with that. However, I believe that we shouldn't do that even if we ignore the implementation cost, because user might submit unexpected data to the web app, for example, if the new window loads a form with auto-focus and user types Enter for the previously focused window.

smaug: What do you think?

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

I can't reproduce this, even if I lower the cpu speed to 1.6Ghz.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #7)

I can't reproduce this, even if I lower the cpu speed to 1.6Ghz.

My point is, I think that we should not enqueue input events while a window is being initialized and flush them later because it may cause sending unexpected data to the web app. So, I think that this should be INVALID or WONTFIX. Do you agree with this? (Although we do similar things in PresShell for other purpose.)

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Oh, sorry. Yes, I agree.