Open Bug 1511756 Opened 2 years ago Updated 2 days ago

A reload on a discarded tab often causes the tab title to be incorrect.


(Firefox :: Tabbed Browser, defect, P3)

64 Branch



Tracking Status
firefox65 --- affected


(Reporter: anonymous30901032, Unassigned, NeedInfo)


(Blocks 1 open bug)



(1 file)

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

Steps to reproduce:

1) Install Tab Unloader extension.
2) Open about 5-10 new tabs with different URLs.
3) Discard those tabs with Tab Unloader (right click on a web page to access it).
4) Right click on discarded tabs without selecting them and click 'Reload Tab' or do a reload all tabs though the menu.

The title of the discarded tabs that were reloaded is often a part of the tab's URL, not the title that was previously showing.
I've tested with the following Add-ons on Noghtly65.0a1 Windos10.
And I can reproduce the issue.

Reproducible: always

Steps To Reproduce:
1. Install one of the above addon or similar addon
2. Open in background tab
   --- observe, tab title is "Wikipedia" as expected
3. Right click on the tab and perform Unload / Discard tab
4. Right click on the tab and perform Reload tab
   --- observe, tab title becomes "" BUG!

Actual Results:
Tab title will be corrupted.

Expected Results:
The tab title should be set correctly.
Component: Untriaged → Tabbed Browser
Ever confirmed: true
Blocks: lazytabs
Priority: -- → P3
See Also: → 1488094
No longer blocks: lazytabs

To test this without add-ons:

var tab = gBrowser.addTab('', {
  createLazyBrowser: true,
  lazyTabTitle: "foobar",
  triggeringPrincipal: Services.scriptSecurityManager.getSystemPrincipal(),
  allowInheritPrincipal: true,
console.log("Title before reload:", tab.label);
  onLocationChange(aBrowser, aWebProgress, aRequest, aLocation, aFlags) {
    if (aBrowser === tab.linkedBrowser) {
      console.log("Title after reload:", tab.label);


Title before reload: foobar
Title after reload:

It should be Example Domain after the reload.

See Also: → 1624083

I have observed also that while tabs.onUpdated will report the same incorrect title showing in the tabs bar (the url actually), a call to tabs.get() will show the correct one (title).

I am uploading a demo addon which demonstrates the behavior initially reported, as well as the title reporting behavior.

To use:

  1. Create and open Firefox in new profile.

  2. Install demo addon.

  3. Close all tabs except 1.

  4. Open 6 new additional tabs, and load with the following urls:

(Wikipedia pages are good for this demonstration as their titles and urls are concise and similar.)

  1. Click on the first tab (the non-Wikipedia tab) to make it the active one. (The active tab won't get suspended)

  2. Click on the demo addon toolbar button (Green square with "test" in it.)

  3. In browserAction popup click on the "suspend tabs" button

  4. After a few seconds, in browserAction popup click on the "run script" button

  5. Observe the tab throbbers indicating tabs are reloading in sequence one by one

  6. After tabs finish reloading, observe the printout of results in the browserAction popup textarea. Several entries will appear for each tab showing the title at a given time and from a given method. Entries preceded by "update" are from tabs.onUpdated, entries preceded by "get" are from tabs.get(). The long number string is a UNIX timestamp.

One can see how while tabs.onUpdated reports the incorrect titles (urls) displayed in the tabs, tabs.get()displays the correct title. One might at first think that the tabs.get() title correction is due to the delay incurred, however note how the same discrepancy occurs early on before the title switches to "New Tab", which seems to indicate there is some other reason.

(In reply to JulianHofstadter from comment #3)

  1. Observe the tab throbbers indicating tabs are reloading in sequence one by one

Observe also that once the tab finishes loading the title has changed to the url of the tab.

Component: Tabbed Browser

Speeding through some linked bugs … might Session Restore be a more appropriate component here?

The title propagation from content (browser.contentTitle) is ignored because the tab object has a pending attribute:

The pending attribute is only removed in two places, (markTabAsRestoring (not relevant in this test case) and _resetLocalTabRestoringState, which is (among others) called at SessionStoreInternal._restoreTabContentComplete. This latter is called when the "SessionStore:restoreTabContentComplete" message is received.

But the tabbrowser implementation (for lazy/discarded tabs) starts with (re)loading the new content (which can trigger title changes) when the "SSTabRestoring" event is triggered, by _restoreHistoryComplete when the "SessionStore:restoreHistoryComplete" message is received.

"SessionStore:restoreHistoryComplete" happens before "SessionStore:restoreTabContentComplete", so when the reload method of the lazy browser starts to reload the page, early title changes are ignored.

I have some questions that may lead to a resolution of this bug (references to code in the above paragraphs):

  • Is the call to "reload" for a lazy browser at SSTabRestoring (in tabbrowser.js) the right time? Why is reload call initiated at this time, why not earlier or later?
  • Is it possible to remove the "pending" attribute (maintained by SessionStore.jsm) before the tab is reloaded (by tabbrowser.js)
  • If not, is it possible to trigger gBrowser.setTabTitle(tab) when the pending attribute is removed?
Flags: needinfo?(dao+bmo)
See Also: → 961016
You need to log in before you can comment on or make changes to this bug.