User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0 Build ID: 20170726100241 Steps to reproduce: Dear all, From the migration to e10s Firefox no longer sends the correct events when coming back in a form field after opening the context menu. Users would to open this menu to check miss spelled word. Steps to reproduce: 1. Enable e10s 2. Focus on an input text 3. Type miss spelled word 4. Use context menu and replace with a suggestion. Actual results: The focus is lost, impossible to continue to input text. Expected results: The focus should be still enabled.

This seems to be a problem in Linux only, cannot reproduce on Windows. We did have a similar problem on Windows once, see bug 1309271, which had to do with the way focus was transitioning between content and the popup in the chrome process. Perhaps Linux needs something similar?

This sounds painful, hopefully we can get to it before too long.

FI, I can only reproduce the issue while the Orca screen reader is running (and only with e10s enabled, as reported)

Actually, right after replacing with a suggestion, I can type almost anything: anything that is not a letter works fine, and also the z, f, j, w, n letters work fine, other a-y letters get the focus lost. Also worth noting, the manner by which the focus is lost varies depending on the letter being typed. My impression is that Orca is taking these letters as a navigation shortcut. Does this ring a bell?

Ah, alex told me that you already explained that it's firefox which doesn't send to Orca the event notifying that we are back to the form.

I have digged a bit in what Orca sees. Firefox does seem to be notifying that the form is getting back focus, but it seems that scripts in Orca get disturbed by another event. Here is what I see happening: - On going around in the contextual menu, orca receives object:state-changed:focused events as appropriate. - On choosing a spell replacement, orca first receives a caret-moved event for the entry (I guess that it's due to the text replacement), and it happens that in scripts/web/script.py, onCaretMoved(), in the "not _settingsManager.getSetting('caretNavigationEnabled') or self._inFocusMode or isEditable:" case, orca calls orca.setLocusOfFocus(event, event.source, False) - that setLocusOfFocus call sets orca_state.locusOfFocus to the entry, but since the notifyScript parameter is set to False, it does not call the script, and thus scripts/web/script.py's locusOfFocusChanged() is not called and it thus does not call self.togglePresentationMode(None), and _inFocusMode thus remains False - right after that, orca receives the object:state-changed:focused event for the entry, orca.setLocusOfFocus is rightfuly called, but it exits immediately since orca_state.locusOfFocus is already the entry, and thus scripts/web/script.py's locusOfFocusChanged() is not called there either, and thus _inFocusMode remains False for good. So one odd thing is that firefox emits the caret-moved event before emitting the object:state-changed:focused event. But that could also happen if something moves the caret in a non-focused entry before making it focused. Here it's simply the spelling replacement. I'm not sure which fix is right, should onCaretMoved not set notifyScript to False? At least it does seem to me that the firefox behavior is not out of bounds, and orca's web scripts could be made more robust here.

I'll see about fixing this in Orca and get back to you.

I think the right behavior is to ignore the caret-moved event in this particular case and let the focus events we get afterwards do their normal thing. This solves the problem for me.

Sorry to be spammy: For now I made the change in Orca tailored to just context menus. While I agree that there are undoubtedly other things which can move the caret in a non-focused entry, I'd rather identify and fix them rather than make a bigger change that might break other things. Sadly, the functional nature of the accessibility events (tells us what happened, leaving us to guess why it happened) is problematic. :(

I can confirm that it fixes the issue, thanks!!

(In reply to Samuel Thibault from comment #10) > I can confirm that it fixes the issue, thanks!! Do you think we need to fix something in Firefox so? Best regards, Alex.

No, I believe we can make it INVALID here.

It seems nor Samuel nor me could change the status of this bug. We think we could mark it as invalid, Marco, what do you think? Best regards, Alex.