[linux] new window context menu hotkey can open in tab
Categories
(Firefox :: Menus, defect, P3)
Tracking
()
People
(Reporter: zlice555, Unassigned)
Details
Attachments
(1 file)
28.84 KB,
text/plain
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:101.0) Gecko/20100101 Firefox/101.0
Steps to reproduce:
On Linux, quickly performing a Right Click and pressing 'd' for Open in New Window.
Actual results:
Performing quickly can open in new tab instead of a window. I have done this several times for a few nightly releases now (maybe since 99? hard to say).
Does not happen in Private Window but unsure if this is because it is a different hotkey.
Expected results:
Open in New Window consistently every time.
System Info
- Void Linux 5.17.2
- gtk+-2.24.33_1
- gtk+3-3.24.31_1
I wish I could attach about:support to my user profile on here.
possibly related
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Menus' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•3 years ago
|
||
Hello! I have tried to reproduce the issue with firefox 101.0a1 (2022-04-27) on Ubuntu 20.04 unfortunately I wasn't able to reproduce the issue.
Could you please answer the following questions in order to further investigate this issue?
- Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
- Does this issue happen in the latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
- Do you have any addons installed if so can you list them?
The profile was just rebuilt and still happening.
The rest of the info is already in about_support.txt
Comment 4•3 years ago
|
||
I don't understand how this could happen. The 'd' accesskey is not shared by other items, and the command for 'open link in new window' doesn't have any code that checks which key was pressed or anything else that would signal a race condition to me. The text for the menu is placed asynchronously, but I can't see how in that case it would trigger a new tab (moreso nothing would happen).
Can you provide any more steps to reproduce?
I thought it may be linking hotkey to actions before the actions are loaded in or in order or something.
I'm just using google searches to trigger it. What all does firefox-profiler capture?
Comment 6•3 years ago
|
||
The firefox-profiler probably wouldn't capture it since it's a sampling profiler and is better suited for repetitive tasks. If you can reproduce it pretty easily, then mozregression would be a good tool to use to see when the behavior changed, https://mozilla.github.io/mozregression/
Unfortunately it's hard to make happen, it will happen for a few moments and then start behaving normally again.
My guess is something threading related holding things up. https://bugzilla.mozilla.org/show_bug.cgi?id=1758561 or other bookmark related issues i've been having since november, or pages being rebuilt https://bugzilla.mozilla.org/show_bug.cgi?id=1766136. Not sure what's responsible for menus randomly closing or doing the incorrect thing like this.
Comment 8•3 years ago
|
||
Thanks for the reply. Unfortunately this is unlikely to get fixed without more steps to reproduce or a better understanding of what causes this. I'm going to mark priority and severity based on your initial bug report, but leave it as "unconfirmed" until we have steps-to-reproduce.
I understand. Hopefully it's related to bookmark issues or something else and gets fixed by proxy
Reporter | ||
Comment 10•3 years ago
|
||
Possibly related to ~/.local/share/fonts directory retriggering GUI rebuilds even when empty. Other bugs I have posted appeared to be fixed by this. Able to browse bookmarks and other FF menus have not magically bliped over the past day since I nuked that directory.
Description
•