Closed Bug 408415 Opened 17 years ago Closed 9 years ago

favicon reverts to default if location.href is modified while loading

Categories

(Firefox :: Tabbed Browser, defect)

Product:
Firefox
Component:
Tabbed Browser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 47
Tracking Flags:
Tracking Status
firefox47 --- fixed

People

(Reporter: bella.spam, Assigned: Gijs)

References

Details

Attachments

(1 file)

MozReview Request: Bug 408415 - fix favicon disappearance for hash changes during load, r?jaws
58 bytes, text/x-review-board-request
jaws
: review+
Details 
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

For the sake of the example, assume the following code is in /Users/bella/Desktop/test.html
and here is the content:

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link rel="shortcut icon" href="https://www.google.com/a/google.com/images/favicon.ico" type="image/x-icon">
<script type="text/javascript">
function reload() { 
  if (window.location.href != "file:///Users/bella/Desktop/test.html#") {
    window.location.href="file:///Users/bella/Desktop/test.html#"
  } 
}
reload()
</script>
</head>
<body>
</body>
</html>

So what I'm trying to do is redirect the user to the original url plus the # sign.



Reproducible: Always

Steps to Reproduce:
1. Go to file:///Users/bella/Desktop/test.html
2.
3.
Actual Results:  
The favicon is shown while the page is loading, but as soon as it gets to the redirect, the favicon reverts to the default (favicon.ico  in the server's root dir).

Expected Results:  
The favicon specified in the <link> tag should be used.
We discovered this issue in Firefox 3.6.8. The following html-code allows to reproduce the issue:

---
<html>
<head>
<title> The Demo Store </title>
<link rel="shortcut icon" type="image/x-icon" href="https://www.motorsportsmarketingresources.com/assets/images/favicon.ico">
</head>

<body>
<script type="text/javascript" src="https://app.ecwid.com/script.js?141461"></script>
<script type="text/javascript"> xProductBrowser("categoriesPerRow=3","views=grid(3,3) list(10) table(20)","categoryView=grid","searchView=list","style=");</script>
</div>
<noscript>Your browser does not support JavaScript.<a href="http://app.ecwid.com/jsp/141461/catalog">HTML version of this store</a></noscript>

<script>
if (!document.location.hash) {
var ecwid_amp = String.fromCharCode(38);
document.location.hash = 'ecwid:category=0' + ecwid_amp + 'mode=product' + ecwid_amp + 'product=1178205';
}
</script>
</body>
---

We hope the new information will help you to fix the issue.

Thank you in advance.
Reporter, are you still seeing this issue with Firefox 3.6.13 or later in safe mode? If not, please close. These links can help you in your testing.
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Managing+profiles
Whiteboard: [CLOSEME 2011-1-30]
Component: General → DOM
Product: Firefox → Core
QA Contact: general → general
Whiteboard: [CLOSEME 2011-1-30]
I can confirm this issue for both 3.6.15pre and 4.0b13pre (2011-03-01).

Changing href or in fact any modification of the address url using location.replace() or location.assign(), causes the favicon change, but in a different manner in 3 and 4 versions.

1. In 3.6.15pre, favicon just disappears. No requests are made back to the server.

2. In 4.0b13pre, FF calls the server back for GET /favicon.ico and it does not respect existing <link rel="shortcut icon" />.

Here is the test page. Put any favicon.ico in images/ directory:

<!DOCTYPE html>
<html>
<head>
<link type="image/x-icon" rel="shortcut icon" href="images/favicon.ico"/>
<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js"></script>
<script type="text/javascript">$(document).ready(function() { location.href="#test"; });</script>
</head>
<body>
</body>
</html>

If you comment out location.href="#test";, then everything is fine. This example does not cause a GET in version 4, if the page is viewed directly from the file system, but will cause it, if served from the server.

Thanks.
I don't know if this is related, but some of the Wikia-hosted wikis will revert the saved custom bookmark favicon to the generic wikia "W" at random -- even while displaying the correct favicon at the address bar. A reload will refresh the saved icon, but sometime later it will again revert to the Wikia "W".

Custom wiki favicons are loaded by a meta tag, while the generic blue W seems to be loaded from the server root at http://www.wikia.com/favicon.ico
i've noticed this problem on my personal site as well. hoping to hear a workaround/fix in this thread...

Problem:
icons work normally on all of www.elstonphotography.com

a link with a # such as http://www.elstonphotography.com/admin/portfolio/weddings.shtml#773 makes the icon disappear. previously going to the next photo in the slideshow did not update the hash and the icon stayed there just fine. in other words once each photo updated the hash, the favicon disappeared.
This bug might explain why my WAR application's favicon (href=http://location:8080/myapp/favicon.ico) keeps getting replaced by JBoss's default favicon (href=http://location:8080/favicon.ico).

In my case, I have a GWT application that uses the com.google.gwt.user.client.History class with a complex #fragment. Basically, I split the fragment up into parameters (c.f. a query string) with each parameter controlling the state of a particular GWT widget. And I have noticed that the favicon changes to the JBoss default one unless the #fragment's string value stays *exactly* the same while the module is loading.

I have observed this bug using Firefox 12 on both Win7 and Linux. However, neither IE9 nor Chrome is affected.
Confirmed for Firefox 31. Wow, this bug 7 years old!

I created testcase http://coolcmd.axspace.com/temp/408415/408415.html
Load it. favicon is disappear because of location.replace().

Now load it with hash, for example http://coolcmd.axspace.com/temp/408415/408415.html#408415
Green favicon is shown.
Status: UNCONFIRMED → NEW
Ever confirmed: true
See Also: → 519028
https://reviewboard.mozilla.org/r/34357/#review31051

::: browser/base/content/tabbrowser.xml:768
(Diff revision 1)
> -                if (this.mTab.hasAttribute("soundplaying") &&
> +                if (this.mTab.hasAttribute("soundplaying") && !isSameDocument) {
> -                    (!this.mBrowser.lastURI ||
> -                     this.mBrowser.lastURI.spec != aLocation.spec)) {

Note that this is a subtle behaviour change. We will now:

- clear the soundplaying attribute if you refresh the same URL
- not clear it if you pushState() or use location.hash to change the location of the page.

I believe that both of those changes are correct, but I could be wrong. Probably worth testing on e.g. youtube, which I believe uses pushState to navigate from the homepage to individual videos. I did some naive testing and didn't see issues, but part of why I asked you (Jared) for review here is because ISTR you reviewed some of the other patches for this functionality.
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Component: DOM → Tabbed Browser
Product: Core → Firefox
See Also: 519028 → 
Comment on attachment 8717897 [details]
MozReview Request: Bug 408415 - fix favicon disappearance for hash changes during load, r?jaws

https://reviewboard.mozilla.org/r/34357/#review31073

Yes, this looks fine.

::: browser/base/content/test/general/browser_bug408415.js:11
(Diff revision 1)
>      let expectedIcon = testPath + "file_bug550565_favicon.ico";

Considering you copied file_bug550565_popup.html to file_bug408415_popup.html but didn't change anything, you might as well copy file_bug550565_favicon.ico to file_bug408415_favicon.ico.

Alternatively, and preferably, you should just rename file_bug550565_favicon.ico to generic_favicon.ico (since there is nothing special about the favicon itself like invalid encoding etc).

I'm assuming you copied the support files so in the future people don't assume they only affected the test for bug 550565.
Attachment #8717897 - Flags: review?(jaws) → review+
https://reviewboard.mozilla.org/r/34357/#review31077

This is a very different approach than I expected based on when I started to debug this many years ago in bug 519028. IIRC the issue was that a URI with a fragment was getting passed to some C++ (either docshell or Places favicon related) and that method would give an error since it couldn't handle the fragment (perhaps constructing a principal?).

Perhaps this higher-level fix works, assuming we still listen for <link> changes after a hash change. If we're still passing a fragment to that lower-level function it could still cause other problems.

This is at least moving in the right direction so I'm fine with landing and thanks for fixing this bug that has annoyed me for years :)
Now if only we could get bug 798249 fixed ;)
https://hg.mozilla.org/integration/fx-team/rev/13e9875fff24
(In reply to (Limited internet connection 2/12) Jared Wein [:jaws] (please needinfo? me) from comment #11)
> Alternatively, and preferably, you should just rename
> file_bug550565_favicon.ico to generic_favicon.ico (since there is nothing
> special about the favicon itself like invalid encoding etc).
> 
> I'm assuming you copied the support files so in the future people don't
> assume they only affected the test for bug 550565.

I renamed both files and changed their contents to make it clear they were not just used by the test for bug 550565.

remote:   https://hg.mozilla.org/integration/fx-team/rev/13e9875fff24
https://hg.mozilla.org/mozilla-central/rev/13e9875fff24
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox47: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 47
Depends on: 1260701
No longer depends on: 1260701
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: