To test this without add-ons:

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

Result:

Title before reload: foobar
Title after reload: example.com/

It should be Example Domain after the reload.

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:

en.wikipedia.org/wiki/Train
en.wikipedia.org/wiki/Car
en.wikipedia.org/wiki/Bus
en.wikipedia.org/wiki/Ship
en.wikipedia.org/wiki/Bicycle
en.wikipedia.org/wiki/Motorcycle

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

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

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

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

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

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

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

9. 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:

• https://searchfox.org/mozilla-central/rev/52a3b19a3de21546f6ab9c10d37d6047107ed874/browser/base/content/tabbrowser.js#5437
• logic was introduced in https://hg.mozilla.org/mozilla-central/rev/6b0f990a4e68#l1.10 for bug 961016

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?

This bug seems to have been fixed. I tested reloading discarded tabs in Firefox 97, 98, and 99. I tested tabs that were discarded by an extension and tabs that were created with a discarded property of true by an extension. The tab titles were all correct.

Only fixed with fission.autostart = true.

This bug seems to get fixed with Services.appinfo.sessionHistoryInParent true.

Maybe the needinfo is no longer needed?

(In reply to kernp25 from comment #10)

This bug seems to get fixed with Services.appinfo.sessionHistoryInParent true.

Maybe the needinfo is no longer needed?

Needinfo could still be relevant, but if you are able to come up with a unit test that consistently passes, then that would be an acceptable way to resolve this bug :)

The severity field for this bug is relatively low, S3. However, the bug has 50 votes and 6 See Also bugs.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.