Merging single tab with other window counts as closing the tab/window (CTRL+SHIFT+N reopens tab)
Categories
(Firefox :: Session Restore, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox124 | --- | affected |
| firefox125 | --- | affected |
| firefox126 | --- | affected |
People
(Reporter: eirik, Unassigned)
References
Details
(Whiteboard: [fidefe-session-restore])
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:126.0) Gecko/20100101 Firefox/126.0
Steps to reproduce:
If you have 2 Firefox windows open, with one tab on each window. And then you drag one of the tabs over to the other window (merging them) so that you now only have 1 window with 2 tabs in it. The tab you moved counts as being closed. If you then press CTRL+SHIFT+N it reopens the tab in a new window even though the tab is still open in the other window.
Expected results:
I don't think single tab windows that merge with tabs on other windows should count as being closed. CTRL+SHIFT+N should instead open the last window that was actually closed (not merged with another window).
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Session Restore' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•1 year ago
|
||
Thanks for filing this. I'm going to call this a bug because as you say the tab is already open in window 2. The window has been closed because once the tab got dragged out of it, it became empty. I think I would expect undo to either re-open the closed window and move the tab back to the re-opened window. Or just re-open the closed window. Or, to ignore this tab move/window close entirely and undo whatever happened previous to that.
We don't currently keep any data on a window that is empty when it is closed, so re-opening it would simply open a new window. If we re-open the tab in that window, we should definitely (re)move it from its current window.
The original window gets closed as an indirect consequence of moving the tab. I think you could argue this was not a user-initiated action so it doesn't make sense to treat the window closure as an undo-able action. And our undo stack is only tracking tab and window closure. It doesn't track tab moves.
So this falls neatly between the cracks. I'm interested in what anyone thinks should happen in this scenario.
Updated•1 year ago
|
Comment 3•1 year ago
|
||
I can reproduce this issue in Nightly v126.0a1, Beta v125.01 (RC), and Release v124.0.2, but not in ESR v115.9.1esr.
Description
•