Click on pinned tab opens it in a new windows [Mac, fullscreen, containers?]
Categories
(Core :: Widget: Cocoa, defect, P3)
Tracking
()
People
(Reporter: contact, Unassigned)
Details
Attachments
(1 file)
607.30 KB,
video/mp4
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:124.0) Gecko/20100101 Firefox/124.0
Steps to reproduce:
I click on tabs to navigate between them, with a macbook trackpad or a Apple mouse
Actual results:
The clicked tab opens in a new window
Expected results:
The clicked tab stays in its actual windows
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Tabbed Browser' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•1 year ago
|
||
From the movie I see
- user appears to be in fullscreen on a mac (possibly the movie is cutting off the menu bar?)
- the user is viewing a pinned mastodon tab
- the user clicks on a second pinned mastodon tab (in a different container, if that's relevant)
- Mac switches to a new desktop to show the second fullscreen mastodon tab, but now it appears to be an unpinned tab in its own window (no other tabs visible)
Note: this scenario is unique to mac: on other OSes the toolbar is not shown when in application-fullscreen mode. It would be impossible to click another tab like this. Mac OS is also unique in using separate desktops to implement fullscreen.
I can't reproduce using the above guesses, though I'm not signed in to that specific mastodon server and I don't know if there are any "only in this container" restrictions set up. Could there be some kind of a Single Sign-on auth that navigates to a different domain? That might cause a pinned tab to navigate to a new tab, but not a new window. And when I tried the login flow it appeared to be the normal mastodon same-origin flow that shouldn't have done either one.
Please confirm or correct my guesses about the exact scenario involved. Any other details you can provide will be helpful.
Hi,
- This is indeed in fullscreen on a mac
- It was appearing on every tab, not just Mastodon
But I have to say that since few days, the bug disappeared... I don't know why. I will let you know if it comes back.
Comment 4•1 year ago
|
||
Have you seen this happen in the last week? Otherwise it seems we can close this.
Updated•1 year ago
|
Updated•1 year ago
|
Comment 5•1 year ago
|
||
Hello! I have tried to reproduce the issue with firefox 127.0a1(2024-05-12) on MacOS 12.6 on Imac, unfortunately I wasn't able to reproduce the issue on my end.
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 yes could you please list them?
Comment 6•11 months ago
|
||
Created an account to +1 on this bug.
I am also seeing this issue, currently running Firefox 127.0.2 on macOS Sonoma 14.5. This bug has been present for ~a few months, not sure I experienced this e.g. last year.
Additionally, this is not restricted to pinned tabs: this behavior can be seen with regular tabs too. I haven't figured out exact steps, but it seems to be somewhat easier to reproduce by cmd-clicking on a link and then clicking on the new tab. When hunting for the reproduction, look out for seeing a white rectangle appear when clicking the tab. It seems like an unintended dragging event gets fired fairly easily on a click, even if it doesn't always result in the tab getting dragged out to a new window.
Low-confidence speculation, I wonder if this could be a lead or completely unrelated. Compare these two behaviors:
- In a macOS fullscreen (virtual desktop view; not just maximized windowed mode), click-and-hold on a tab and drag upwards. You cannot get the tab to detach this way - if you push far enough, you will see the desktop switcher view, but letting go will not drop the tab out. Even if you'd keep dragging the held tab to another desktop (with or without Firefox windows), it will not actually move when you let go.*
- In the same macOS fullscreen view, first move your cursor far enough up that you see the menu bar and the window bar decorations appear. Now move your cursor to a tab, click-and-hold, drag upwards, and now the tab detaches really easily, spawning a new window. I wonder if it is possible that this is related: maybe a cursor movement that has gone close enough to the top has started a (possibly imperceptible) state change for showing the menu and window bar, and the click on the tab ends up being interpreted as a drag event over the top of the window frame?
(* Sidenote: I wonder if this should be a separate UX bug too. You cannot easily move tabs between fullscreen Firefox windows. You have to either merge the desktops to a split window view and then drag the tab across, or when dragging a tab across desktops, keep waiting for a few seconds until the view zooms in fully to the application, and then drag the tab into its place. Combined with the current bug, this is slightly aggravating - it takes only a fraction of a second to end up spawning a new window on a new desktop, and multiple frustrating seconds to get it back where it belongs.)
Comment 7•11 months ago
|
||
Forgot to mention another piece of low-confidence speculation: I wonder if this is more likely to happen on tabs that are not fully loaded yet - e.g. new tabs, or pinned tabs that have not been touched since a reboot / session restore? It maybe feels that way, but could also be a red herring.
Comment 8•7 months ago
|
||
A needinfo is requested from the reporter, however, the reporter is inactive on Bugzilla. Given that the bug is still UNCONFIRMED
, closing the bug as incomplete.
For more information, please visit BugBot documentation.
Description
•