I started doing some work on the TabbingOrderHighlighter to ensure that when EFT is enabled, he highlighters for the element of a given page are displayed by their target (even if this does not have any impact for the end user).

To do this, I planned on refactoring https://searchfox.org/mozilla-central/rev/bc5e79f3ae0f42cb4a6ebd05fc32f48a3829059d/devtools/server/actors/highlighters/tabbing-order.js#80-95 so it would only return a contentDOMReference if the focus was moved to a subiframe.

This highlighted an issue with Services.focus where getFocusedElementForWindow isn't updated directly, and we don't get any event to know when the expected value is set (see Bug 1741601).

In the end, this revealed that the TabbingOrderHighlighter is working due to some luck when Fission is enabled.

So let's say we have this structure

<!-- https://example.com/... -->
html
  button#top
  iframe src="https://example.org/..."
    html
      button#in-remote-frame

The user starts the highlighter in the UI, which calls TabbingOrderHighlighterActor#show.
At the beginning of show we move the focus forward:

• moveFocus returns : button#top , which we assign to currentFocusedElement
• this.focusedElement is: button#top

html
  [[button#top]]
  iframe src="https://example.org/..."
    html
      button#in-remote-frame

Then we start looping with the while.
On the first iteration, we move the focus forward again

• moveFocus returns : null , which we assign to currentFocusedElement
• this.focusedElement is still button#top (because of Bug 1741601)
• actual focused element is the html element of the remote iframe

html
  button#top
  iframe src="https://example.org/..."
    [[html]]
      button#in-remote-frame

At this point we're done looping, and we send back the client the reference of this.focusedElement, which is button#top.

From the client, given this reference, we retrieve its target, and then call TabbingOrderHighlighter#show, this time with a startElement being the NodeFront for button#top

Back to TabbingOrderHighlighterActor#show
At the beginning of show we move the focus forward, starting from the button:

• moveFocus returns null (as the next focusable element is the iframe html element) :
• but luckily, this RDP roundrip gave enough time so this.focusedElement does return iframe now

And so we return the reference of the iframe element to the client, which will detect it's an iframe with its own target, and will call TabbingOrderHighlighterActor#show on the iframe target.

We're quite lucky here, and ideally, we would only have a single call to TabbingOrderHighlighterActor#show for the top-level target, which would directly return the reference to the iframe.

Fixing this depends on the information we get on Bug 1741601, and this might require a totally different approach than the one we're currently using.