[e10s] XUL add-on testing for being in writable zone sometimes fail.

RESOLVED INVALID

Status

()

Core
Event Handling
P2
normal
RESOLVED INVALID
2 years ago
2 years ago

People

(Reporter: michael, Unassigned)

Tracking

49 Branch
Points:
---

Firefox Tracking Flags

(e10s+)

Details

(Whiteboard: triaged)

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

2 years ago
Created attachment 8760217 [details]
Screencap of the action.  I start typing "aaa" then an "h", which goes to the previous tab instead of being input.  Then I go back to the tab, and "h" works as expected.

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.
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.
Flags: needinfo?(michael)
(Reporter)

Comment 2

2 years ago
Created attachment 8761519 [details]
minimalXUL-0.0.1.xpi

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

Comment 3

2 years ago
Created attachment 8761523 [details]
event-bug.mp4

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.
Attachment #8760217 - Attachment is obsolete: true
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.
Status: UNCONFIRMED → NEW
tracking-e10s: --- → ?
Component: Untriaged → Event Handling
Ever confirmed: true
Flags: needinfo?(michael)
Product: Firefox → Core
Summary: XUL add-on testing for being in writable zone sometimes fail. → [e10s] XUL add-on testing for being in writable zone sometimes fail.

Updated

2 years ago
Blocks: 905436
tracking-e10s: ? → +
Flags: needinfo?(sescalante)
(Reporter)

Comment 5

2 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).

Updated

2 years ago
Flags: needinfo?(sescalante) → needinfo?(masayuki)
Whiteboard: triaged
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.
Flags: needinfo?(masayuki)
Priority: -- → P2
(Reporter)

Comment 7

2 years ago
Created attachment 8784768 [details]
A XUL addon that prints on the console whether the user types in an input zone.

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.
Attachment #8761519 - Attachment is obsolete: true
Maybe Masayuki can take a look at the attachment from comment 7 when he has time. Marking needinfo to get it on his radar.
Flags: needinfo?(masayuki)
(Reporter)

Comment 9

2 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!
Thanks Michael for the update.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(masayuki)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.