1138466 - Keyboard Stopped working

Status: RESOLVED DUPLICATE of bug 1137229

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

Description

[agustinpetruccelli]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150302004030

Steps to reproduce:

I couldn´t find Firefox DeleloperEdition as a product, so I posted the bug here. Right now I´m using the version 38.0a2 but this problem happens since a week or ten days ago. My computer is a Macbook Pro 13" with OXS 10.8.5

It´s dificult to reproduce because it´s appear to be a random error.




Actual results:

I´m using normally the browser and suddenly the keyboard stop working. This happens 4 or 5 times per day and I have to restart Firefox. I can use the mouse and navigate, but I can´t type anything anywhere. I can´t write an email, complete a form or even type an URL in the navigation bar, nothing. 


Expected results:

I expect to use the keyboard while I´m using your software...

Comment 1

[Mats Palmgren (inactive)]

Can you try opening a new window (File menu) using the mouse next time this happens
and let us know if keyboard input works in that window?  Thanks.

Comment 2

[Mats Palmgren (inactive)]

Additional questions: if you click on the URL bar when the keyboard problem occurs,
do you see a blinking caret? is the URL bar highlighted with a focus outline?

Comment 3

[Mats Palmgren (inactive)]

Masayuki-san, could the problem be caused by IME? it sounds like the problem is some
global state that's wrong somehow.  Is it possible to disable IME for testing purposes?

Comment 4

[agustinpetruccelli]

(In reply to Mats Palmgren (:mats) from comment #1)
> Can you try opening a new window (File menu) using the mouse next time this
> happens
> and let us know if keyboard input works in that window?  Thanks.

Good idea, if I open a new window it works fine.

Comment 5

[agustinpetruccelli]

(In reply to Mats Palmgren (:mats) from comment #2)
> Additional questions: if you click on the URL bar when the keyboard problem
> occurs,
> do you see a blinking caret? is the URL bar highlighted with a focus outline?

It´s normal. The caret blinking and everything is normal. No difference between the error window and the new window were it works.

Bye!

Comment 6

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

[Tracking Requested - why for this release]:
Rather horrible regression

Comment 7

[Chris Ilias [:cilias]]

Possible dupe of bug 1137229.
I'm seeing this too, so I did a quick search on bugs mentioning "keyboard" since the beginning of February.

Comment 8

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

(In reply to Mats Palmgren (:mats) from comment #3)
> Masayuki-san, could the problem be caused by IME? it sounds like the problem
> is some
> global state that's wrong somehow.

I'm not sure.

On Mac OS X, we do just not call super view's interpretKeyEvents while IME is disabled (i.e., while nobody doesn't have focus or a non-editable element has focus like button).
http://mxr.mozilla.org/mozilla-central/source/widget/cocoa/TextInputHandler.mm?rev=50b89dc93750#1582

Even if we don't call it, insertText must be called because we need to dispatch keypress event and it's dispatched from insertText if the key is a printable key.
http://mxr.mozilla.org/mozilla-central/source/widget/cocoa/TextInputHandler.mm?rev=50b89dc93750#2139

This will be handled as shortcut key like Command + C.

>  Is it possible to disable IME for
> testing purposes?

No way. However, reporter can log the behavior with NSPR_LOG_FILE=~/fx.log NSPR_LOG_MODULES=TextInputHandlerWidgets:5.

Note that don't post the log file without trimming key event logs caused by your usual usage because it may include your sensitive information like passwords. Please post only the logs some key presses which is tested intentionally after this bug is reproduced.

Comment 9

[Liz Henry (:lizzard)]

[Tracking Requested - why for this release]:

Tracking this since it sounds like a bad regression. If we dupe it to bug 1137229 please nominate it for tracking there.

Comment 10

[JB]

I am seeing this behavior also in beta 37 on OSX Yosemite.  I notice it when NoScript extension is active.   Haven't noticed with other extensions but could be...

Keyboard stops accepting inputs anywhere in Firefox - address bar, fields, etc. -- but works normally in other apps.  Focusing on other apps then returning to Firefox doesn't help.  Only thing that works is a restart of Firefox.

Comment 11

[Chris Ilias [:cilias]]

I don't have NoScript, but I assume pasting about:support data would be helpful, so here's mine: https://pastebin.mozilla.org/8825003

Comment 12

[Lawrence Mandel [:lmandel] (use needinfo)]

Tracking 37+ on both reported bugs at this point.

Comment 13

[Steven Michaud [:smichaud] (Retired)]

Whoever sees this bug, please test with builds dated 2014-02-20 and earlier -- especially m-c and Developer Edition nightlies.  Be sure to test with e10s mode off.

Those builds don't contain my patch for bug 1110888.

Comment 14

[JB]

Updating my prior comment (10) to note that the issue occurs even without NoScript installed.

Opening a new window does fix the problem in the new window -- but not in the original window.

Comment 15

[Steven Michaud [:smichaud] (Retired)]

Here's the opt tryserver build from bug 1137229 comment #27:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-7f8185f65f28/try-macosx64/firefox-39.0a1.en-US.mac.dmg

Whoever sees this bug please test with it (until the patch for bug 1137229 lands on mozilla-central).

Comment 16

[Steven Michaud [:smichaud] (Retired)]

The patch for bug 1137229 is in today's mozilla-central nightly.

Whoever sees this bug, please test with it.

Comment 17

[Lawrence Mandel [:lmandel] (use needinfo)]

Can you still reproduce with the latest Firefox Developer Edition?

Comment 18

[Lawrence Mandel [:lmandel] (use needinfo)]

I'm marking this as a dup of bug 1137229 but, given the severity of the issue, I'm going to keep the tracking and status flags in case this is not a dup and needs to be reopened.