307066 - no favicon after click on anchor link

Status: VERIFIED FIXED

(SeaMonkey :: Tabbed Browser, defect)

Description

[Bruno 'Aqualon' Escherl]

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.

Reproducible: Always

Steps to Reproduce:
1. Go to the URL
2. Click on one of the anchors

Actual Results:  
Default icon replaces bugzilla favicon.

Expected Results:  
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.

Comment 1

[Dave Townsend [:mossop]]

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.

Comment 2

[Dave Townsend [:mossop]]

Would hope to see this sorted by 1.5

Comment 3

[Bruno 'Aqualon' Escherl]

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.

Bruno

Comment 4

[Bruno 'Aqualon' Escherl]

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.

Bruno

Comment 5

[Asa Dotzler [:asa]]

When did this break for Firefox?

Comment 6

[Dave Townsend [:mossop]]

*** Bug 308487 has been marked as a duplicate of this bug. ***

Comment 7

[u81239]

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.


~Grauw

Comment 8

[Dave Townsend [:mossop]]

Tracked this to between 2005061306 and 2005061406.
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=AviarySuiteBranchTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-06-13+06%3A15&maxdate=2005-06-14+06%3A07&cvsroot=%2Fcvsroot

Bug 109672 looks like a likely culprit.

Comment 9

[Christian Schmidt]

Attachment: Fix

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
bug 302575.

Comment 10

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 196247 [details] [diff] [review]
Fix

r=vladimir

This should fix the common problem case; users manually typing in #foo isn't
all that common, I don't think.

Comment 11

[u81239]

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


~Grauw

Comment 12

[Christian Schmidt]

> 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
302575.

Comment 13

[Asa Dotzler [:asa]]

please land on the trunk and resolve the bug so we can get a trunk verification
before accepting on the branch. thanks.

Comment 14

[Asa Dotzler [:asa]]

vlad, can you get this landed on the trukn s owe can evaluate for the branch?

Comment 15

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

This was landed by mconnor yesterday; resolving for trunk.

Comment 16

[Scott MacGregor]

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.

Comment 17

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Yes, doing so now; was bogged down by landing cairo 1.0 on trunk.

Comment 18

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Yes, doing so now; was bogged down by landing cairo 1.0 on trunk.

Comment 19

[Tracy Walker [:tracy]]

Verified with Windows and Mac 2.0b1rc3 builds 

Comment 20

[Aleksis]

I found, that site favicon hides, when I change hash of document url, like that:
jQuery(function(){
  location.hash = "somehash";
});