Last Comment Bug 307066 - no favicon after click on anchor link
: no favicon after click on anchor link
Status: VERIFIED FIXED
: regression, verified1.8
Product: SeaMonkey
Classification: Client Software
Component: Tabbed Browser (show other bugs)
: 1.8 Branch
: All All
: -- normal (vote)
: mozilla1.8beta5
Assigned To: Vladimir Vukicevic [:vlad] [:vladv]
:
:
Mentors:
https://bugzilla.mozilla.org/show_bug...
: 308487 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-04 16:33 PDT by Bruno 'Aqualon' Escherl
Modified: 2013-07-15 04:13 PDT (History)
10 users (show)
asa: blocking1.8b5+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Fix (1.46 KB, patch)
2005-09-15 15:00 PDT, Christian Schmidt
vladimir: review+
asa: approval1.8b5+
Details | Diff | Splinter Review

Description Bruno 'Aqualon' Escherl 2005-09-04 16:33:56 PDT
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] 2005-09-04 17:48:06 PDT
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] 2005-09-04 17:49:19 PDT
Would hope to see this sorted by 1.5
Comment 3 Bruno 'Aqualon' Escherl 2005-09-05 02:09:19 PDT
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 2005-09-05 02:40:52 PDT
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] 2005-09-13 10:03:26 PDT
When did this break for Firefox?
Comment 6 Dave Townsend [:mossop] 2005-09-14 07:21:41 PDT
*** Bug 308487 has been marked as a duplicate of this bug. ***
Comment 7 Laurens Holst 2005-09-14 07:26:39 PDT
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 9 Christian Schmidt 2005-09-15 15:00:53 PDT
Created attachment 196247 [details] [diff] [review]
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] 2005-09-15 17:20:39 PDT
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 Laurens Holst 2005-09-16 03:48:42 PDT
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 2005-09-16 04:16:20 PDT
> 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] 2005-09-16 11:27:04 PDT
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] 2005-09-21 11:13:08 PDT
vlad, can you get this landed on the trukn s owe can evaluate for the branch?
Comment 15 Vladimir Vukicevic [:vlad] [:vladv] 2005-09-21 12:24:21 PDT
This was landed by mconnor yesterday; resolving for trunk.
Comment 16 Scott MacGregor 2005-09-27 15:45:27 PDT
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] 2005-09-27 15:57:08 PDT
Yes, doing so now; was bogged down by landing cairo 1.0 on trunk.
Comment 18 Vladimir Vukicevic [:vlad] [:vladv] 2005-09-27 15:59:46 PDT
Yes, doing so now; was bogged down by landing cairo 1.0 on trunk.
Comment 19 Tracy Walker [:tracy] 2006-07-11 12:49:48 PDT
Verified with Windows and Mac 2.0b1rc3 builds 
Comment 20 Aleksis 2013-07-15 04:13:59 PDT
I found, that site favicon hides, when I change hash of document url, like that:
jQuery(function(){
  location.hash = "somehash";
});

Note You need to log in before you can comment on or make changes to this bug.