Closed Bug 961016 Opened 9 years ago Closed 9 years ago

When starting Firefox, Unloaded background tabs don't have icon


(Firefox :: Session Restore, defect)

Not set



Firefox 29


(Reporter: avih, Assigned: ttaubert)



(Keywords: regression)


(1 file)

Starting with today's nightly, when Firefox starts, background tabs which are unloaded don't have an icon.

I was told by ttaubert that it could be a regression from bug 942374.
I'm just going to blame bug 942374 until we know otherwise.
Blocks: 942374
Keywords: regression
So yeah, I can 100% reproduce that. Pinned tabs have icons, unpinned have not. The title seems also not set properly, it's just the URL.
The webNavigation.stop() call in ContentRestore.restoreHistory() overrides the icon set by SessionStore.restoreTabs(). This needs to happen on :restoreHistoryComplete. This does fix the icon but the label is somehow still overriden with the URL...
browser.stop() seems to override a DOMTitleChanged event that overrides pending tabs' titles. This also seems to be the cause for all pinned tabs "glowing" after the session has been restored.
I assume that stopping the tab load right after it has been created suppresses the DOMTitleChanged event for about:blank somehow. The little gap we have by sending a message probably lets the page load far enough to emit that.
Duplicate of this bug: 961061
I also see this on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 ID:20140117030207 CSet: 9bcc52594322 so broadening the platform a bit.
OS: Mac OS X → All
Hardware: x86 → All
This patch sets a pending tab's icon and label after its history has been restored and the about:blank load has been cancelled. The test ensures that we won't regress this again.

Dao, asking for review on the tabbrowser.xml change that ignores DOMTitleChanged events for pending tabs, as soon as the tab has started loading and we use an async message to call "browser.stop()" there seems to be no way to cancel that event. We don't want that titles for pending tabs change and that seems better than trying to catch the event and stop it.
Assignee: nobody → ttaubert
Attachment #8361775 - Flags: review?(wmccloskey)
Attachment #8361775 - Flags: review?(dao)
Keywords: verifyme
Comment on attachment 8361775 [details] [diff] [review]

Review of attachment 8361775 [details] [diff] [review]:

Thanks Tim.
Attachment #8361775 - Flags: review?(wmccloskey) → review+
Comment on attachment 8361775 [details] [diff] [review]

>--- a/browser/base/content/tabbrowser.xml
>+++ b/browser/base/content/tabbrowser.xml
>@@ -3186,16 +3186,19 @@
>           if (!event.isTrusted)
>             return;
>           var contentWin =;
>           if (contentWin !=
>             return;
>           var tab = this._getTabForContentWindow(contentWin);
>+          if (tab.hasAttribute("pending"))
>+            return;

Seems like you should similarly update the e10s code path in the receiveMessage method.
Attachment #8361775 - Flags: review?(dao) → review+
Duplicate of this bug: 961411
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
Duplicate of this bug: 961518
Duplicate of this bug: 961653
Duplicate of this bug: 961716
Verified on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0
Keywords: verifyme
Duplicate of this bug: 962507
Blocks: 963068
See Also: → 1511756
You need to log in before you can comment on or make changes to this bug.