Bookmark to about:blank shows favicon from random pages

NEW
Assigned to

Status

()

Firefox
Bookmarks & History
P3
normal
2 years ago
8 months ago

People

(Reporter: Jonathan Allard, Assigned: billm)

Tracking

({regression})

44 Branch
regression
Points:
---

Firefox Tracking Flags

(e10s+)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Created attachment 8688541 [details]
Screen Shot 2015-11-17 at 13.11.50.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20151117004023

Steps to reproduce:

1. Add bookmark to `about:blank` on the Bookmarks toolbar
2. Use Firefox for a while


Actual results:

The bookmark favicon will be of another site/page


Expected results:

The favicon should either be blank or generic
(Reporter)

Comment 1

2 years ago
I don't remember a previous version of Firefox that didn't have this bug, it's been happening as long as I've had such a bookmark. I'd be curious to know why it happens, as it is seemingly random.

Comment 2

2 years ago
I can also reproduce on Windows7

This seems to be e10s only bug.

Reproducible: 100%

STR:
1. Add bookmark to `about:blank` on the Bookmarks toolbar
2. Open web page ( e.g., https://developer.mozilla.org/en-US/Add-ons/Code_snippets )
3. Open about:config or about:buildconfig etc.
Status: UNCONFIRMED → NEW
tracking-e10s: --- → ?
Ever confirmed: true

Comment 3

2 years ago
Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=473627b1b002&tochange=22d78dbf4b3a

Regressed by: 22d78dbf4b3a	Bill McCloskey — Bug 1056443 - Use correct URL in location bar when switching processes (r=ttaubert)
Blocks: 1056443
Flags: needinfo?(wmccloskey)
Keywords: regression
Kicking back into e10s triage.  Yes, this bug is e10s specific. But I believe this isn't a very common use case.  How many people actualy bookmark about:blank (it is not "Starable"). In addition, only power users would be accessing about:config. I could not get the favicon to change by visiting real sites.
Component: Location Bar → Bookmarks & History
Flags: needinfo?(wmccloskey)
Flags: needinfo?(wmccloskey)
Assignee: nobody → wmccloskey
tracking-e10s: ? → m9+
Flags: needinfo?(wmccloskey)
tracking-e10s: m9+ → +
Priority: -- → P1

Updated

2 years ago
Duplicate of this bug: 1247180

Comment 6

2 years ago
Having same problem here.

STR: in my case
1. Open about:config and bookmark it
2. Go to any web page with favicon
3. Go back

Updated

2 years ago
Priority: P1 → P3

Comment 7

a year ago
Investigation code:
--- a/browser/components/sessionstore/SessionStore.jsm
+++ b/browser/components/sessionstore/SessionStore.jsm
@@ -892,6 +892,8 @@ var SessionStoreInternal = {
         if ("image" in tabData) {
           // Use the serialized contentPrincipal with the new icon load.
           let loadingPrincipal = Utils.deserializePrincipal(tabData.iconLoadingPrincipal);
+          console.log("setIcon [" + tabData.image + "] for ["
+            + win.gBrowser.currentURI.spec + "] @SessionStore:restoreHistoryComplete");
           win.gBrowser.setIcon(tab, tabData.image, loadingPrincipal);
           TabStateCache.update(browser, { image: null, iconLoadingPrincipal: null });
         }

--- a/browser/components/sessionstore/TabState.jsm
+++ b/browser/components/sessionstore/TabState.jsm
@@ -18,6 +18,8 @@ XPCOMUtils.defineLazyModuleGetter(this, 
   "resource:///modules/sessionstore/TabAttributes.jsm");
 XPCOMUtils.defineLazyModuleGetter(this, "Utils",
   "resource://gre/modules/sessionstore/Utils.jsm");
+XPCOMUtils.defineLazyModuleGetter(this, "console",
+  "resource://gre/modules/Console.jsm");
 
 /**
  * Module that contains tab state collection methods.
@@ -119,10 +121,15 @@ var TabStateInternal = {
     // be read from the tab/browser every time we collect data.
 
     // Store the tab icon.
+    let cached = true;
     if (!("image" in tabData)) {
       let tabbrowser = tab.ownerGlobal.gBrowser;
       tabData.image = tabbrowser.getIcon(tab);
+      cached = false;
     }
+    console.log((cached ? "cached" : "getIcon") + " [" + tabData.image + "] for ["
+      + tabData.entries[tabData.index - 1].url + "] on ["
+      + browser.currentURI.spec + "] @_collectBaseTabData");
 
     // Store the serialized contentPrincipal of this tab to use for the icon.
     if (!("iconLoadingPrincipal" in tabData)) {

Investigation steps:
1. Start firefox with a new profile.
2. Open local file.
3. Go to web page.
4. Make sure icons in menu>History.
5. Go back.
6. Look icons in menu>History.
Actual result:
The local file have a favicon as same as the web page.
Expected result:
The local file have the globe icon instead of any favicon.

Since I'm not an expert, I could imagine at least two or more workarounds instantly.
A. Check url of tab and browser in TabState.jsm. (I don't think it is reasonable, though)
B. Remove >if (!("image" in tabData))< (I believe it will not degrade performance because getIcon is not heavy, but I'm not understanding the reason why if this if-statement should not be removed)
C. Check if the favicon should load before invoking setIcon in SessionStore.jsm. 8-|
D. Remove >win.gBrowser.setIcon(tab, tabData.image, loadingPrincipal);<  (correct favicon appears without this statement/mechanism)
and
E. Don't update the cache with the last image and the changed index @SessionStore.navigateAndRestore>restoreTab>TabStateCache.update. :-/
You need to log in before you can comment on or make changes to this bug.