1871176 - [Wayland] Firefox 119 and above version randomly lost web-ext's input focus on wayland when using keyboard shortcut to popup the web-ext's window

Status: UNCONFIRMED

(Core :: Widget: Gtk, defect, P3)

Description

[Onion]

Attachment: firefox-wayland.log

Steps to reproduce:

• system: archlinux latest 2023-12-21
• platform: x86_64
• window manager: sway
• firefox env: MOZ_ENABLE_WAYLAND=1
• firefox version: 119 ~ 122beta
• web-ext used for test: Search Bookmarks, History and Tabs
• steps:
  1. set its popup shorcut to M-x (meta key is ALT in most of case)
  2. open several newtabs with non-internal page
  3. trigger that popup shortcut repeatly, you will see sometimes its
     top input box get focused but some times not while you can type
     any char to see that without any inputs posted on.

When such unfocused occasion occurred, I found that we can using tab
key to focely let it be focused where I suspect that the original
input focus is in somewhere of firefox main window.

Actual results:

In any firefox major version upper than 118 (for now at least until
122beta) can reproduce this bug on popular wayland implementations
(both of mutter and wlroots based DE/WM).

Generally say that any web-ext who has a input box element made as
default input focus place in its main popup.html in manifest.json
will be randomly doesn't get focused at each time popup it only when
this case triggered via a keyboard shortcut set with firefox's
extension shortcut manger on wayland session with condition described
above.

Expected results:

Should consistently has same behaviour as what firefox on X11 did.

Comment 1

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

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

Comment 2

[Martin Stránský [:stransky] (ni? me)]

Can you please try different (nested) compositor?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_different_Wayland_compositor
Thanks.

Comment 3

[Onion]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #2)

Can you please try different (nested) compositor?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_different_Wayland_compositor
Thanks.

Still buggy even on mutter(both native and nested under wlr) as the description shown on my bug post contents.

Comment 4

[Onion]

In addtion, it is is indeed not a [sway/wlroots] individually related bug, I suggest remove the title indiccator of "[sway] xxx".

Comment 5

[Martin Stránský [:stransky] (ni? me)]

Okay, Thanks. Can you use mozregression tool to find broken commit?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
Thanks.

Comment 6

[Onion]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #5)

Okay, Thanks. Can you use mozregression tool to find broken commit?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
Thanks.

Uh.. , pity that my PC disk's left space is not enough to store the firefox's mercurial repo offline, but I guarantee that the final firefox-118.0.2 release is bug free of this post but for any firefox version uppon than that i.e. 119 and later.

Therefore, I guarantee that it's the regression invoked via firefox-119. Hoping this bug can be fixed without pain.

Thanks for mozilla efforts for such the greatest browser against the terrible manifest V3 of GOOGLE CHROME.

Regards ...

Comment 7

[Martin Stránský [:stransky] (ni? me)]

Please try the mozregression tools. It downloads nightly builds from Mozilla, runs them and you can simply midpoint broken release. Please run with MOZ_ENABLE_WAYLAND=1 env variable to get Wayland build.

Also, do you mind to create a screencast of the issue?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Collect_information_for_a_bug_report

Thanks!

Comment 8

[Onion]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #7)

Please try the mozregression tools. It downloads nightly builds from Mozilla, runs them and you can simply midpoint broken release. Please run with MOZ_ENABLE_WAYLAND=1 env variable to get Wayland build.

Also, do you mind to create a screencast of the issue?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Collect_information_for_a_bug_report

Thanks!

I've use mozregression with cmdline mozregression --good 118 --bad 119 find the 119.0a1 (the first alpha ver. of 119) was the regerssion invoker.

screencast gif url: https://tmpfiles.org/dl/4000270/bug1871176_2024-01-27_an.gif

Which is as same as what I said that firefox 119 was the regression point other than any version under it.

Comment 9

[Onion]

since prev upload was removed from host server

New screencast gif url: https://i.imgur.com/GWvRiOA.gif

Comment 10

[Martin Stránský [:stransky] (ni? me)]

(In reply to Onion from comment #8)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #7)

Please try the mozregression tools. It downloads nightly builds from Mozilla, runs them and you can simply midpoint broken release. Please run with MOZ_ENABLE_WAYLAND=1 env variable to get Wayland build.

Also, do you mind to create a screencast of the issue?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Collect_information_for_a_bug_report

Thanks!

I've use mozregression with cmdline mozregression --good 118 --bad 119 find the 119.0a1 (the first alpha ver. of 119) was the regerssion invoker.

Great. Can you paste mozregression output here? It should print changes which leads to the regression.
Thanks.

Comment 11

[Onion]

Great. Can you paste mozregression output here? It should print changes which leads to the regression.
Thanks.

Nope, it's just a UI visualization debug regression test, the mozregression just asked for whether 119.0.a1 is "BAD", and therefore I touch "yes".

The mozregression tool is not a programmer who has intelligent to parse what regression on its UI aspect, there's no need to use it for debug this regression anymore, instead, we should find the "code" logical regerssion.

Thanks.

Comment 12

[Martin Stránský [:stransky] (ni? me)]

The mozregression tools downloads various Firefox build from Mozilla and you check if they're good or bad. By bisecting it can find particular code changes as it can download build with various patches included. And then it should print regression range, i.e. which code is changed between final good -> bad builds. So please give it a try and find the regression range.
Thanks.