Caret browsing causes document to claim focus when Right Arrow is pressed at end of table

Steps to reproduce:

1. Launch Firefox with caret browsing enabled (F7) and load Gmail
2. Launch the attached accessible-event-listener
3. Arrow Down within the list of messages
4. Arrow Right repeatedly until you reach the end of the table (with the date)
5. Arrow Right one more time

Expected results: The document would not claim focus.

Actual results: The document claims focus. Example output:

Note: I reached the end of the table via Right Arrow:
[table cell | Sun, Apr 5, 2020, 3:59 PM] is now focused

Note: I pressed Right Arrow one more time:
[document web | Inbox (16) - joanmarie.diggs@gmail.com - Gmail] is now focused

Impact: Orca is updating its position to the newly-focused document and switching to browse mode which it shouldn't because functionally the user hasn't left the list of messages.

Note: If you do not enable caret browsing or toggle it off, this problem doesn't happen.

(In reply to Joanmarie Diggs from comment #0)

Impact: Orca is updating its position to the newly-focused document and switching to browse mode which it shouldn't because functionally the user hasn't left the list of messages.

I'm probably missing something here, but if you press right arrow at the edge of the table, won't that move the caret out of the table? At that point, the user has left the list of messages? In the same way that with this:

data:text/html,<a href="https://mozilla.org/">foo</a> bar

pressing right arrow to move out of "foo" focuses the document.

Jamie: So maybe GMail needs to steal left/right arrow whenever the user is inside the grid....

(In reply to Joanmarie Diggs from comment #2)

Jamie: So maybe GMail needs to steal left/right arrow whenever the user is inside the grid....

Perhaps? I totally get that this particular scenario isn't ideal, but I also don't think Firefox is doing anything "incorrect" here. The whole point of caret browsing is to allow the user to move the caret through the document. Screen readers have browse mode and focus mode concepts which allow them to differentiate behaviour for interactive and non-interactive widgets, but browser caret browsing doesn't. You could argue it should, but that's a whole different feature and would require caret browsing to consider stuff such as ARIA. That opens up another can of worms, since ARIA is only supposed to affect a11y tree exposure.

Closing as wontfix given this, but happy to discuss further and reconsider if there's something I'm missing.