Tabs moved to a new window may not be duplicated
Categories
(Firefox :: Session Restore, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr91 | --- | unaffected |
| firefox-esr102 | --- | unaffected |
| firefox104 | --- | wontfix |
| firefox105 | --- | wontfix |
| firefox106 | --- | wontfix |
People
(Reporter: mozbz, Unassigned)
Details
(Keywords: regression)
Tabs that have been moved from one window to another often cannot be Duplicated. A workaround is to copy the URL in to a new tab - this tab may be freely duplicated.
"Open Link in New Window" appears not to be affected.
STR:
0. Create a new profile.
- Open Firefox. Two tabs open on first run, but if not, open two different pages.
- From the second tab's Context Menu select "Move Tab > Move to a New Window".
- In the new window, from the moved tab's Context Menu select "Duplicate Tab"
Expected Results:
The tab should be duplicated, loading a new copy of the same URL.
Actual Results:
A New Tab is opened.
mozregression narrowed to here, although I found reproduction gets more sporadic further back. I couldn't reproduce it at all in 102. This range includes two commits for bug1739450 :
INFO: Last good revision: cda3070eb374a8d2ae68ac381e1ff706ba93abda
INFO: First bad revision: 7f523f9cd22dd9dffb5db8a7de2631fd5c759e02
INFO: Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=cda3070eb374a8d2ae68ac381e1ff706ba93abda&tochange=7f523f9cd22dd9dffb5db8a7de2631fd5c759e02
Comment 1•3 years ago
|
||
The severity field is not set for this bug.
:dao, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 2•3 years ago
|
||
Setting Regressed by field after analyzing regression range found by mozregression in comment #0.
Comment 3•3 years ago
|
||
Set release status flags based on info from the regressing bug 1739450
Updated•3 years ago
|
Comment 4•3 years ago
|
||
The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.
Comment 5•3 years ago
•
|
||
I don't believe that regression range from comment 0 is correct, the regressor landed 2022-04-20 but 101.0a1 (2022-04-30) is not affected. Also checked 102.2.0esr and is not affected.
The regression seems to be somewhere in 103: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=43f3eb2819ccc2324512c7c782e19ec7b998a84e&tochange=0e44540919cda05e29992605143ca7a7b6982926
Mozregression consistently points toward: Bug 1774242 - Make sure invariants for the test is correct. r=Gijs , but I don't find it likely. Gijs, can you confirm/infirm?
Later edit: 102.0a1 (2022-05-29) also not affected.
Comment 6•3 years ago
|
||
(In reply to Adrian Florinescu [:aflorinescu] from comment #5)
I don't believe that regression range from comment 0 is correct, the regressor landed 2022-04-20 but 101.0a1 (2022-04-30) is not affected. Also checked 102.2.0esr and is not affected.
The regression seems to be somewhere in 103: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=43f3eb2819ccc2324512c7c782e19ec7b998a84e&tochange=0e44540919cda05e29992605143ca7a7b6982926Mozregression consistently points toward: Bug 1774242 - Make sure invariants for the test is correct. r=Gijs , but I don't find it likely. Gijs, can you confirm/infirm?
Probably not that bug but some of the patches from related bugs that Andreas landed at the same time (bug 1756995) seem very plausible. The originally suggested regression window (bug 1739450) also sounds plausible. Andreas is out, passing this to Peter for investigation.
Note that esr not being affected could be to do with how much of the session restore SHIP code got enabled at what time (ie maybe nightly was affected but we didn't ship at the time). Hopefully Peter knows more about when what shipped without digging through bugzilla as much as I'd have to do...
Updated•3 years ago
|
Updated•3 years ago
|
Comment 7•3 years ago
|
||
Setting Regressed by field after analyzing regression range found by mozregression in comment #0.
Comment 9•1 year ago
|
||
Per comment #8, sounds like this may be fixed - reporter, are you still seeing this?
| Reporter | ||
Comment 10•1 year ago
|
||
Hello! I used to run in to this regularly, but it certainly stopped happening at some point. However, my environment has also changed in the interrim so I wasn't sure what the ettiquette was for closing the bug.
I'm not able to reproduce this in ESR 115.11 or a recent Nightly, so I'm happy to have the bug closed if there's no objections.
A big thank you to whoever is responsible for fixing it, even if it was by accident!
Comment 11•1 year ago
|
||
Thanks for the super quick response! Let's close this out then. We can always reopen / file new bugs if this starts recurring.
Description
•