1752269 - Media control in deezer stealing keyboard focus when song change on Linux

Status: UNCONFIRMED

(Core :: Widget: Gtk, defect)

Description

[@fanf42]

Attachment: 2022-01-26-firefox stealing keyboard focus.mp4

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0

Steps to reproduce:

I'm on Linux (archlinux) with X windows on firefox 96. My desktop environment is configured so that no windows should get focus (even children windows of current window).
Go to deezer and start playing some music. Then go anywhere else, be it in firefox or on other application. When the song change, keyboard focus is stolen by the media controls. This seems to happen only if the song play all along (ie, if you put the song near the end to try to speed-up the test, it does not work).

It also happened when I'm on another tab writting a bug report for example: keyboard focus is lost from the input field (and the whole tab actually), and I need to interactively give it back to the field with the mouse.

Actual results:

Keyboard focus stolen from the application I'm working on and reverted to deezer media control in firefox.
See attached video of the behavior: I was continually writting "e" in the terminal, and it stopped with lost of keyboard focus.
It's likely a security problem too, since focus stealing was exploited in the past to trap people.

Expected results:

No focus stealing EVER. If I'm on a different application, that my desktop environment tells "never steal focus", then firefox must prevent it, whatever the underlying site try to do.
And even if my desktop if not configured so, firefox should prevent an other tab from stealing focus from current tab.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::DOM: UI Events & Focus Handling' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Hsin-Yi Tsai (she/her)[:hsinyi]]

Masayuki, can you take a look at this? Focus stealing is annoying and concerning. Thank you.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Hmm, the website requires an account to show the page...

According to the symptom, it seems that this is not Firefox's issue because the reporter said that "My desktop environment is configured so that no windows should get focus (even children windows of current window)". But our request from nsWindow::SetFocus is accepted by GTK.

@fanf42: Thank you for your bug report. Could you tell us how to configure the settings which you set in your environment?

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

If the requested window is already visible, the API just calls gdk_toplevel_focus.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gtkwindow.c#L5354

Then, it calls focus method of the window class.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gdk/gdktoplevel.c#L377

its implementations are:
wayland: https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gdk/wayland/gdksurface-wayland.c#L5050
x11: https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gdk/x11/gdksurface-x11.c#L5172

They just call:
gdk_wayland_surface_focus: https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gdk/wayland/gdksurface-wayland.c#L3457
gdk_x11_surface_focus: https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gdk/x11/gdksurface-x11.c#L2194

But they don't check permission etc. So I wonder, do GTK apps support the feature? I think that the better component is Widget:GTK, but let's ask karlt.

karlt: Do you know something about this issue? Is this caused by Gecko's specific issue or GTK's issue?

Comment 5

[Karl Tomlinson (:karlt)]

This is surprising behavior.

The window manager ultimately controls which window has focus.
Often this is determined from timestamps in the application focus requests but the "never steal focus" setting mentioned here might mean that such requests should be ignored regardless of timestamp values. What is the window manager in this report?

Running Firefox from the terminal with "MOZ_LOG=MediaControl:5,Widget:5,ContentMediaController:5" in the environment should produce a log that might have some clues.

If timestamps are being used, then bug 1236153 comment 5 has the program that I would use to debug that.

Comment 6

[@fanf42]

@Masayuki: the accounts are free from a desktop, so you should be able to reproduce. It should just need a valid email for confirmation.

For the dektop config, I'm under enlightenment, so I believe it can be a not common case - but I really just have that behavior under firefox, and on that specific site. For example, I don't have a focus loss on youtube when a video ends and the next starts.
I reported the problem on enlightenment irc/issue tracker, and their devs (Raster) believes it's maybe something between X and firefox overriding enlightenment on that case.
If it helps (perhaps the wording used can ring a bell), the settings I'm using for windows focus are:

• most recent window under the mouse
• focus policy: sloppy [other choices: click, pointer]
• new windows focus: no windows [other choices: all windows, only dialogs, only dialogs with focused parent]
• autoraise: never
• raise: when starting to move or resize
• active window hint policy: ignore hint
• misc: alway pass click events to program: yes; click raise window: no; click focuses window: no; refocuse last window on desktop switch: yes; allow focusing of sticky windows when reverting focus: no; focus last focused window on lost focus: yes

(I tried to change that last one, since it seems it could be linked, but it doesn't change the focus stealing - I had a hope, because it didn't happened on first song, but then I remembered that the behavior only happens after the second one, which is borderline insane)

@Karl: I tried the debug, but I'm sorry, I didn't understood what you mean with the timestamp or what is explained on linked post.
I join the part of logs when it happens and a video capturing when it happens. It seems to be on a Dispatch event positionstatechange (but it's quick, perhaps it's a bit latter on Controller 103 grants audio focus).
The files are 2022-02-04-firefox stealing keyboard focus debug.mp4 and 2022-02-04-firefox stealing keyboard focus debug.txt

Comment 7

[@fanf42]

Attachment: Video of debug log output to pinpoint when the stealing happens

Comment 8

[@fanf42]

Attachment: MediaControl logs arounds time of focus loss

Comment 9

[Karl Tomlinson (:karlt)]

Alastor, are you aware of any way in which MediaController might interact with system keyboard focus?

Is there a pref that would disable MediaController in order to test whether that might be involved here?

Comment 10

[Alastor Wu [:alwu]]

Interesting, would it be an issue specifically related with the reporter's linux deskop enviroment? So far I've not heard any issue where MPRIS would steal the window focus, I also couldn't reproduce this issue on my Ubuntu 20.04. Firefox uses dbus to update and monitor signals, but none of them are related with windows focus.

Yes you can use media.hardwaremediakeys.enabled to disable the media control feature.

Comment 11

[@fanf42]

Sorry, I didn't saw your answers before today. I wanted to test the proposed option, but unfortunatly deezer shipped an update to their site and now it's totally broken under firefox: only the first song is played in playlist, and the "next" (or going to next at the end of the first one) doesn't work anymore. There is really something fishy with the way they switch songs.
I'm wondering if it has anything to do with ads that should pop at the end (or middle or whatever) of each song - and I'm using ublock origin.

So, in the midtime, I tested under chromium, and sadly, everything is working fine with it: no focus stealing, UI working (even with ublock their, too - or ublock behave differently on ff and chromium).

So, clearly deezer engineering are just not caring at all about firefox, and I will need to change for an other service (I tried to contact them, but I'm not holding my breath for an answer: https://twitter.com/fanf42/status/1492589279473807371).

I'm still wondering what makes firefox allows focus stealing on that case, and I would love to see it corrected, it's always a can of abuse worms waiting to happen.

Comment 12

[@fanf42]

So, Deezer team deployed a new version of their app that seems to have make things better:

• the songs go to next now ;)
• sometimes, the focus is not stolen on song change. But sometime, it is. For now, I weren't able to discover patterns. This is a bit frustrating.

Comment 13

[Gian-Carlo Pascutto [:gcp]]

I'm going to triage down as apparently we have problems reproducing it, so I can't imagine this is very common.