User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050901 SeaMonkey/1.1a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050901 SeaMonkey/1.1a
When you visit a website with a favicon and #named anchor links in it, the
favicon is replaced by the default one after you click on one of the links.
Steps to Reproduce:
1. Go to the URL
2. Click on one of the anchors
Default icon replaces bugzilla favicon.
Show the bugzilla favicon.
Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050901
SeaMonkey/1.1a with fix for Bug 306810 in it, but the problem also occurs with
older SeaMonkey builds.
This hits firefox as well on both branch and trunk nightlies. Doesnt occur in
1.0.6. Also reported on linux by ispiked. Looks similar to the ancient bug 262486.
Would hope to see this sorted by 1.5
I tried the oldest SeaMonkey Build I found (Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.8b2) Gecko/20050705 SeaMonkey/1.0a) and the bug exists there.
Bug 262486 is literally the same, but was only related to Firefox at that time.
I'll check a 1.7 Suite build later.
Checked two older builds and the both show this bug
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050904
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.2) Gecko/20040426
I think the bug was never intentionally fixed for the suite and perhaps in
firefox it was a side effect of another patch.
When did this break for Firefox?
*** Bug 308487 has been marked as a duplicate of this bug. ***
Losing the favicon is a usibility problem when using tabbed browsing.
At backbase.com we are using fragment identifiers heavily to navigate to pages
within an Ajax single page interface.
Tracked this to between 2005061306 and 2005061406.
Bug 109672 looks like a likely culprit.
Created attachment 196247 [details] [diff] [review]
This fixes the problem when clicking on anchor links.
The problem is that onStateChanged isn't called when navigating to an anchor on
the same page.
There is still a problem if you go to http://example.com/ and then enter
http://example.com/#foo in the URL bar and press Enter. This will still reset
the favicon. This appears to be related to userTypedValue, but I'm not sure I
fully understand that part of the code. This problem may be fixed together with
Comment on attachment 196247 [details] [diff] [review]
This should fix the common problem case; users manually typing in #foo isn't
all that common, I don't think.
Thanks for the fix...
(In reply to comment #10)
> This should fix the common problem case; users manually typing in #foo isn't
> all that common, I don't think.
Well, I reasonably often copy and paste an address to a part of a specification
from my email client into my webbrowser...
> Well, I reasonably often copy and paste an address to a part of a
> specification from my email client into my webbrowser...
The problem only occurs if the URL that you enter points to an anchor on the
page that is already loading. I.e. entering http://example.org/#foo will work,
unless http://example.org/ is already loaded.
But as mentioned I think (hope) that this remaining problem will be fixed in bug
please land on the trunk and resolve the bug so we can get a trunk verification
before accepting on the branch. thanks.
vlad, can you get this landed on the trukn s owe can evaluate for the branch?
This was landed by mconnor yesterday; resolving for trunk.
Looks like this has been on the trunk for a couple days now. Is this ready for
the branch? Can you land this if it is ASAP? Thanks.
Yes, doing so now; was bogged down by landing cairo 1.0 on trunk.
Verified with Windows and Mac 2.0b1rc3 builds
I found, that site favicon hides, when I change hash of document url, like that:
location.hash = "somehash";