michael Reporter
	Description • 8 years ago

User Agent: Mozilla/5.0 (X11; Linux i686; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160605030215

Steps to reproduce:

I have a XUL-based add on, that listens to `keydown`, and on pressing the key `h`, checks whether the user is tying in a text field, and if not, switches to the previous tab.


Actual results:

When the focus to the textbox is given in some sort of sloppy way (or maybe with a text-editable div), the snippet used to detect whether the user is in an editable zone does not work, and the `h` is used as "previous-tab" instead of being used as input.  This is *even if* other characters have been input before.  The code to detect editability is:

	var command = 'cmd_insertText';
	var controller = document.commandDispatcher.getControllerForCommand(command);
	return (controller && controller.isCommandEnabled(command));

This returns false.


Expected results:

The snippet should return true, and the `h` should be input in the textbox.

	Cosmin Muntean [:cmuntean], Ecosystem QA (PTO until September 8th)
	Comment 1 • 8 years ago

Could you please attached the add-on so we can test this issue? Also can you please provide a new screen recording of the issue using the on-screen keyboard to see exactly the steps to reproduce? Maybe this link can help you http://xmodulo.com/onscreen-virtual-keyboard-linux.html.

	michael Reporter
	Comment 2 • 8 years ago

Minimal XUL add-on to detect when the user is typing in an input zone.

	michael Reporter
	Comment 3 • 8 years ago

New screen cap using virtual keyboard and the attached minimal add-on.  When "a" is first typed, the add-on report *not* being in an input zone.  After a back and forth to another tab, it does.

	Cosmin Muntean [:cmuntean], Ecosystem QA (PTO until September 8th)
	Comment 4 • 8 years ago

Firefox: 50.0a1, Build ID  20160608030219
User Agent: Mozilla/5.0 (X11; Linux i686; rv:50.0) Gecko/20100101 Firefox/50.0

I have tested this issue on the latest Firefox (47.0) and latest Nightly (50.0a1) on Windows 7 x64 and Ubuntu 14.04. I have managed to reproduce it only on Nightly with e10s enabled on the gmails, mail reply form. 
On the release version and on Nightly build with e10s disabled the issue is not reproducible.

	michael Reporter
	Comment 5 • 8 years ago

I can confirm that disabling e10s (I'm using Nightly) gets rid of the bug, whether it be in Gmail, or the other websites affected (including Facebook).

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900)
	Comment 6 • 8 years ago

I don't know about command controller implementation in e10s mode.

But you can use nsIDOMWindowUtils.IMEStatus if user can type text with focused element even in a content process.  When IMEStatus is nsIDOMWindowUtils.IME_STATUS_DISABLED, there is no focused element or focused element isn't text inputtable. Perhaps, checking cmd_insertText isn't plugin-aware.

	michael Reporter
	Comment 7 • 8 years ago

My XUL-foo (or really, any -foo) being quite bad, I may have misunderstood what Masayuki proposed—from what I can witness, it does not work.  Here is an updated version of the XUL plugin that checks for IMEStatus; it seems that IMEStatus is never nsIDOMWindowUtils.IME_STATUS_DISABLED.

	Andrew Overholt [:overholt]
	Comment 8 • 8 years ago

Maybe Masayuki can take a look at the attachment from comment 7 when he has time. Marking needinfo to get it on his radar.

	michael Reporter
	Comment 9 • 8 years ago

My bad; I didn't use nsIDOMWindowUtils properly.  Using the suggested way to obtain the interface in:

  https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDOMWindowUtils

this works flawlessly.  This could go to WONTFIX as far as I'm concerned, though it may hide a bigger problem.  Thanks!

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 10 • 8 years ago

Thanks Michael for the update.