1724205 - private tabs discarded earlier during their creation are not restored with the expected original url

Status: RESOLVED FIXED

(WebExtensions :: Untriaged, defect, P3)

Description

[u665825]

Attachment: capture-1628166634.mp4

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

1. Install the addon https://addons.mozilla.org/en-US/firefox/addon/dontloadimages/
2. Allow the addon to run in private mode
3. Open a private window
4. Open a new background tabs by clicking on a pagelink (for example via CTRL+left mouse button)
5. Switch to the background tab via ATL+TAB or by clicking on the tab handle

Actual results:

The background displays a blank page

Expected results:

The discarded tab should start loading the page when the tab gets activated just as it does in normal mode

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[u665825]

Thanks bot! :)

Makes sense to me, i guess the web-extension api should not behave differently when the permission to run in private mode is given

Comment 3

[Alex Cornestean]

Hello,

I could not reproduce the issue on the latest Nightly (92.0a1/20210808090543), Beta (91.0/20210804193234) and Release (90.0.2/20210721174149) under Windows 10x64 and Ubuntu 16.04 LTS, as per the provided STR.

The background page opened in Step 4 properly displays content. For further details, see the attached video.

Comment 4

[Alex Cornestean]

Attachment: 2021-08-09_13h27_38.mp4

Comment 5

[u665825]

@Alex
Thanks for taking the time to look into this.
You are right, it seems the issue is already fixed in "90.0a1".
Next time i'll have to remember to first try with the nightly build.

Comment 6

[u665825]

correction i meant "92.0a1"

Comment 7

[u665825]

@Alex, wait ...

i made a mistake ... the behaviour is stil wrong,
In nightly "92.0a1" it now loads the background tab instead preventing the loading until you switch the focus.

I rewatched your video it seems that it is the same for you .
That behaviour still differs from how the non-private window work.

Comment 8

[u665825]

I also quickly tested it with 91.0b9 (current beta)
and unsuprisingly it also shows the same behaviour (as nightly and stable)
I'll update the ticket appropriately.

Comment 9

[Rob Wu [:robwu]]

Could you make the reproduction steps more specific? Which website should we try?

If you have difficulty with explaining the issue, could you share a video and mention the timestamps that are problematic?

Comment 10

[u665825]

@Rob: I'll try, hopefully this is a better step by step description

Steps to reproduce:

1. install the addon 'dontLoadBackgroundTabs' from AMO
2. allow the addon to run in private windows
3. open a new private window (via File > New Private Window or CTRL+SHIFT+P)
4. In the new private window visit "example.net" or any other website
5. Click any link on the website with the LEFT MOUSE BUTTON while holding down CTRL
   or just click it with the MOUSEWHEEL/3rd MOUSE BUTTON
6. Wait for the background tab to be created
7. Switch to the newly created background tab

Expected result:

After switching to the newly created background tab,
the tab should then start loading its content (and not already loading or having loaded it)

Actual result:

The background tab stays blank and does not load the content.

Comment 11

[Alex Cornestean]

Hello,

In light of the new provided STR (Comment 10), I managed to reproduce the issue on the latest Nightly (93.0a1/20210809213353), Beta (92.0b1/20210809172802) and Release (90.0.2/20210721174149) under Windows 10 x64 and Ubuntu 16.04 LTS.

In normal browsing mode, the background tab will not load upon being created. Once I click on it, the content will begin loading. This is as expected.
In private browsing mode, the background tab will, as well, not load once created. But once I click on the tab, content is still NOT loaded, confirming the issue.
For more details, see the attached videos.

I also want to point something out regarding the initial STR. The wrong add-on was referenced there (https://addons.mozilla.org/en-US/firefox/addon/dontloadimages/ instead of https://addons.mozilla.org/en-US/firefox/addon/dontloadbackgroundtabs/ as in the most recent STR). That was why I could not reproduce the issue yesterday.

Comment 12

[Alex Cornestean]

Attachment: private browsing.mp4

Comment 13

[Alex Cornestean]

Attachment: normal browsing.mp4

Comment 14

[u665825]

@alex
You are absolutely right, i linked the wrong addon.
I should have notice that on the first video you provided.
I am terribly sorry!

Comment 15

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: Bug 1724205 - Fix issue on restoring private tabs discarded while being created. r?gijs!,mixedpuppy!

When an extension does call tabs.discard earlier in the tab creation (e.g. when the extension calls
tabs.discard from inside a tabs.onUpdated listener), when the tab is activated (e.g. by selecting
the non-currently active lazified tab) Firefox is expected to restore it to the webpage url that
was being loaded.

This was already working as expected on non-private tabs, where the expected tab url was stored
in the TabStateCache as the userTypedValue (which seems to be part of a fix also related to
tabs.discard and landed in Firefox 62 from Bug 1422588).

It didn't work yet for private tabs, because for a private tab we are storing {isPrivate: true}
into the TabStateCache as soon as we are creating the tab, and so the change to SessionStore
resetBrowserToLazyState applied from Bug 1422588 had no effect for the private tabs
(due to the check for an existing cached entry for the same tab).

This patch applies a small change to ensure we are caching the userTypedValue set on the browser
element if one is not already stored in the TabStateCache, and adds an additional test case
to browser_ext_tabs_discarded.js which cover the expected behavior (and fails as expected
without a fix for the underlying issue).

Comment 16

[Luca Greco [:rpl] [:luca] [:lgreco]]

Push to try for the patch attached in comment 15: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b461619772885b1cc53db2dba5de87375fa30bb3

Comment 17

[Alex Cornestean]

Hello,

Verified the patch via the Try build from Comment 16 on Ubuntu 16.04 LTS as this OS was the only available.
With this build, in private browsing mode, the background tab will not load once created, as in normal browsing mode thus far. Once I click on the tab, content is properly loaded, confirming the fix.

Comment 18

[Luca Greco [:rpl] [:luca] [:lgreco]]

New push to try (test tweaked to prevent intermittent failure while running in debug mode, the debug build's TV job was failing while running in chaos mode):

https://treeherder.mozilla.org/#/jobs?repo=try&revision=846ba54c23e428116f488f54f2ea4cb214eefff1

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/feee34371f46
Fix issue on restoring private tabs discarded while being created. r=Gijs,mixedpuppy

Comment 20

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/feee34371f46