1820692 - If you open a URL in a new Window and then attach it back, the Right Click->"Duplicate" functionality doesnt work

Status: ASSIGNED

(Firefox :: Session Restore, defect)

Description

[Mayank Bansal]

1. Start Nightly with a new profile
2. go to URL-bar and press the down key
   -> A drop-down menu with pre-populated URL will appear
3. use the down key to highlight a URL (e.g. youtube,com) and press Shift+Enter
   -> Youtube.com will open in a new tab in a new window
4. Let youttube.com load completely
5. Attach the tab with youtube.com to the original Window from Step1
6. Right click on the youtube tab->Duplicate

ER: A new tab will open and load youtube.com
AR: A blank tab opens

The steps a somewhat complex. Please see attached video.

Regression:
2023-03-07T08:19:48.290000: DEBUG : Found commit message:
Bug 1774242 - Make sure invariants for the test is correct. r=Gijs

Differential Revision: https://phabricator.services.mozilla.com/D149280

Comment 1

[Mayank Bansal]

Attachment: Bug.mp4

Comment 2

[Mayank Bansal]

Attachment: about:support

Comment 3

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

Set release status flags based on info from the regressing bug 1774242

:farre, since you are the author of the regressor, bug 1774242, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Comment 4

[Mayank Bansal]

I cant repro this If I wait for some time (15 seconds?) after the tab has loaded, and then re-attach it and try to duplicate the tab. This sounds like it may be related to bug 1798232.

In general, I came across this bug accidentally. I dont think that in the real world, u user will open URL in a new tab, re-attach it to the original window and try ti duplicate the tab within a span of 15 seconds. The bug is real, but severity and user impact is very low IMHO.

Comment 5

[Andreas Farre [:farre]]

Bug 1774242 is a test, and no functionality is changed. I'm not sure that it's caused by Bug 1798232, but it may have the same root cause. The fact that waiting 15 seconds solves the issue indicates that there is a missing state sync step after re-attaching. I'd actually expect Bug 1798232 to solve this issue as well.

Comment 6

[Andreas Farre [:farre]]

Right, Bug 1798232 almost fixes it. If you perform the STR but add opening another new tab in the new window before dragging the tab back, then duplicating it works, because we dispatch a TabClose event. But if it's the final tab in the window, we'skip TabClose.

Comment 7

[Andreas Farre [:farre]]

Attachment: Bug 1820692 - Force session history update on fast window close. r=peterv!

When we move the last tab from a window we loose session history if we
do it before the first write to TabStateCache. To not loose session
history we need to force a session history write to the tab state
cache before the window goes away.

Comment 8

[Sam Foster [:sfoster] (he/him)]

I wasn't able to reproduce this with the STR in comment 0; the tab duplicated as expected with the correct page. :farre, do you know if this was already fixed, or is the attached patch still something we want to finish up and land?

Comment 9

[Mayank Bansal]

I can still repro it

Comment 10

[Andreas Farre [:farre]]

The attached patch needs updates, unfortunately. I'll try to see if I can find time to finish it.