695622 - tab doesn't traverse the content process document

Status: RESOLVED WORKSFORME

(Core :: DOM: Content Processes, defect)

Description

[alexander :surkov (:asurkov)]

After tabbing into content process document the next tab gets the focus back to chrome document. The route looks like: tab, addressbar, searchbar, next focusable element in content process document, tab, addressbar and etc.

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Felipe, is this known?

Comment 2

[:Felipe Gomes (needinfo for replies!)]

Yes, it is known. I intentionally left this out of bug 583976 to not make the scope of that bug too big.

From what I recall, I looked at the code at that time and also talked with smaug and it seemed that this shouldn't be too hard to do. If anyone from the a11y team or who understand the focus manager code wants to take this bug, I'd be happy to help.

The way it works right now is that the browser element is treated as a focusable box in the xul UI, and whenever it receives/loses focus, it sends a message to the content to activate/deactivate its focused status.

The change needed is that when <browser remote> is focused and Tab is pressed, losing focus on it has to be delayed and a message sent to the content to focus the next element (there are methods for this already). If a reply is sent saying that the last element was focused, then the FM moves the focus out of browser.

Note that this will make tabbing out of <browser> an asynchronous operation. If this will break assumptions then the FM will have to keep cached state about whether the content is focused on its last element or not.

Comment 3

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

IIRC, this was working in test-ipc.xul at some point, but I guess puppet widget may have broken it.

Comment 4

[alexander :surkov (:asurkov)]

(In reply to Felipe Gomes (:felipe) from comment #2)

> From what I recall, I looked at the code at that time and also talked with
> smaug and it seemed that this shouldn't be too hard to do. If anyone from
> the a11y team or who understand the focus manager code wants to take this
> bug, I'd be happy to help.

Enn, could you take this please?

Comment 5

[Chris Peterson [:cpeterson]]

Mass tracking-e10s flag change. Filter bugmail on "2be0fcce-e36a-4e2c-aa80-0e3d33eb5406".

Comment 6

[:Felipe Gomes (needinfo for replies!)]

Evilpie fixed this in another bug, so it's probably a duplicate (I can't find the bug #). Or is there some a11y-specific behavior missing? If not, can you retest to see if it's indeed fixed for a11y?

Comment 7

[David Bolter [:davidb] (NeedInfo me for attention)]

WFM, Alex?

Comment 8

[alexander :surkov (:asurkov)]

nah that was pure user experience bug with no directly involved a11y, wfm is good if it was fixed