Closed Bug 1724205 Opened 4 months ago Closed 4 months ago

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


(WebExtensions :: Untriaged, defect, P3)

Firefox 90


(firefox90 wontfix, firefox91 wontfix, firefox92 wontfix, firefox93 fixed)

93 Branch
Tracking Status
firefox90 --- wontfix
firefox91 --- wontfix
firefox92 --- wontfix
firefox93 --- fixed


(Reporter: u665825, Assigned: rpl)


(Regressed 1 open bug)



(5 files)

Attached video 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
  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

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.

Product: Firefox → WebExtensions

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


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.

Attached video 2021-08-09_13h27_38.mp4

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.

correction i meant "92.0a1"

@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.

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.

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?

Flags: needinfo?(inbre001)

@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 "" 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.

Flags: needinfo?(inbre001)


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 ( instead of as in the most recent STR). That was why I could not reproduce the issue yesterday.

Ever confirmed: true
Attached video private browsing.mp4
Attached video normal browsing.mp4

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

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).

Assignee: nobody → lgreco
Summary: different behaviour of addon in private browsing mode → private tabs discarded earlier during their creation are not restored with the expected original url


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.

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):

Severity: -- → S3
Priority: -- → P3
Pushed by
Fix issue on restoring private tabs discarded while being created. r=Gijs,mixedpuppy
Regressions: 1725701
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 93 Branch
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.