1920075 - translate steals focus for arrow keys from extension

Status: NEW

(Firefox :: Translations, defect)

Description

[xspecktatorx]

Attachment: firefox_bug.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:130.0) Gecko/20100101 Firefox/130.0

Steps to reproduce:

• Start firefox while having some pages still open from last session (restored) which offer translation
• Instantly click on an extension top open a window for that extension (tested with bitwarden) which has input fields (e.g. text input)
• see the popup asking to translate the page come up
• Try to move inside the input field with the arrow keys or HOME/END

Actual results:

The extensions window stays open but seemingly nothing happens with the arrow keypresses, typing inside of it still works though.

Expected results:

The cursor inside the input field should move to the left or right when pressing the left or right arrow keys, just as it does when the translation popup is not open in the background.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Translations' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Erik Nordin [:nordzilla]]

Attachment: reproduction-attempt.webm

Hi xspecktatorx, thanks for filing this!

I've attempted to reproduce this behavior, but was unsuccessful. Though, I did have to make a few changes to the Steps To Reproduce (STR).

In order to open a page, but delay the opening of the Translations panel until after opening extension-related content, I had to modify the browser.translations.chaos.timeoutMS preference (shown in video). This is a debugging preference that introduces delays into some of the calls for Translations. In this case, it has the effect of delaying the opening of the Translations panel when navigating to a new page. Without this, the panel opens too quickly on my machine for me to open something else first.

Using this modified STR, I was unable to reproduce the behavior from your sceenshot, where the extension content is shown on top of the Translations panel. For me, the Translations panel opens on top of the extension content (shown in video).

Is there something specific that you are doing to create the situation where the extension content is on top of the Translations panel, yet the focus is still on the Translations panel?

Comment 3

[xspecktatorx]

Attachment: translation focus bug

Hey Erik, thanks for the reply!
What I'm doing is basically just opening my browser (after it was closed completely) and opening the extension right away while the page is still loading, nothing special I'd say, no settings changed.
I have a short clip attached that hopefully clarifies what's happening exactly and maybe allows you to reproduce it.
As you can see there, its just the arrow keys that don't work for me.

If there's any other information you need, I'm happy to help!

Comment 4

[Erik Nordin [:nordzilla]]

I appreciate the additional video. Thank you!

I am still unable to reproduce exactly this behavior on my Linux machine, even when restarting the browser, opening to a translatable page.

For me, the extension panel is always shown underneath the Translations panel. Though, this may be a subtle difference between the Windows code and the Linux code within Firefox.

With regard to which panel should appear on top, I think the Linux behavior feels most correct: the Translations panel should be shown on top since it was opened after the extension panel. When the Translations panel appears, it is designed to take the focus. This is necessary for users who are utilizing assistive technology such as screen readers to be able to shift the focus to the panel's content when it opens.

However, when you intentionally click back onto the extension panel, I think the correct behavior would be for the Translations panel to close. It is expected that a panel should close if you click away from it, but something is preventing it in this case.

---

I am going to mark this as confirmed (NEW), because I do think the current behavior here is undesirable. I appreciate you reporting it!

However, I cannot guarantee a specific timeline to prioritize this, since the behavior is easily circumvented by closing the panels and opening the one that you want to use.

---

Please let me know if you have any further thoughts on the desired behavior here. There is always room for discussion.

Comment 5

[xspecktatorx]

Also tested it on my linux machine (arch but I guess that doesn't make much of a difference), user agent: "Mozilla/5.0 (X11; Linux x86_64; rv:130.0) Gecko/20100101 Firefox/130.0" and tried it with a "fresh" nightly, user agent: "Mozilla/5.0 (X11; Linux x86_64; rv:132.0) Gecko/20100101 Firefox/132.0", same problem for me in both cases.

So unfortunately no idea what else could make the difference. Definitely not a huge problem of course, just found it annoying when I started typing and had type it all again because after closing the translation popup the extension closed as well.
This might be an alternative, to just not close the extension window right away but I assume this would cause some other issues. No worries tho if it's just on my end, was just surprised I couldn't find anything about it so I thought I'd report it. But not being reproducible for others explains why it's the first report. 😄

Thanks for your time!