no favicon after click on anchor link

VERIFIED FIXED in mozilla1.8beta5

Status

SeaMonkey
Tabbed Browser
VERIFIED FIXED
12 years ago
4 years ago

People

(Reporter: Bruno 'Aqualon' Escherl, Assigned: vlad)

Tracking

({regression, verified1.8})

1.8 Branch
mozilla1.8beta5
regression, verified1.8
Bug Flags:
blocking1.8b5 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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.
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.
Status: UNCONFIRMED → NEW
Component: XP Apps: GUI Features → Tabbed Browser
Ever confirmed: true
Keywords: regression
OS: Windows XP → All
Product: Mozilla Application Suite → Core
Hardware: PC → All
Version: unspecified → 1.8 Branch
Would hope to see this sorted by 1.5
Flags: blocking1.8b5?
(Reporter)

Comment 3

12 years ago
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
(Reporter)

Comment 4

12 years ago
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

12 years ago
When did this break for Firefox?
*** Bug 308487 has been marked as a duplicate of this bug. ***

Comment 7

12 years ago
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
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

12 years ago
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.
Attachment #196247 - Flags: review?(vladimir)

Updated

12 years ago
Flags: blocking1.8b5? → blocking1.8b5+
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.
Attachment #196247 - Flags: review?(vladimir) → review+

Updated

12 years ago
Attachment #196247 - Flags: approval1.8b5?

Comment 11

12 years ago
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

12 years ago
> 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

12 years ago
please land on the trunk and resolve the bug so we can get a trunk verification
before accepting on the branch. thanks.
Whiteboard: [checkin needed]

Comment 14

12 years ago
vlad, can you get this landed on the trukn s owe can evaluate for the branch?
Assignee: guifeatures → vladimir
This was landed by mconnor yesterday; resolving for trunk.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Whiteboard: [checkin needed]

Updated

12 years ago
Attachment #196247 - Flags: approval1.8b5? → approval1.8b5+

Comment 16

12 years ago
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.
Yes, doing so now; was bogged down by landing cairo 1.0 on trunk.
Keywords: fixed1.8
Target Milestone: --- → mozilla1.8beta5
Verified with Windows and Mac 2.0b1rc3 builds 
Status: RESOLVED → VERIFIED
Keywords: fixed1.8 → verified1.8
Product: Core → SeaMonkey

Comment 20

4 years ago
I found, that site favicon hides, when I change hash of document url, like that:
jQuery(function(){
  location.hash = "somehash";
});
You need to log in before you can comment on or make changes to this bug.