Closed Bug 307066 Opened 15 years ago Closed 15 years ago

no favicon after click on anchor link

Categories

(SeaMonkey :: Tabbed Browser, defect)

1.8 Branch
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.8beta5

People

(Reporter: bugzilla, Assigned: vlad)

References

()

Details

(Keywords: regression, verified1.8)

Attachments

(1 file)

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


~Grauw
Attached patch FixSplinter 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
bug 302575.
Attachment #196247 - Flags: review?(vladimir)
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+
Attachment #196247 - Flags: approval1.8b5?
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
> 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.
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]
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
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [checkin needed]
Attachment #196247 - Flags: approval1.8b5? → approval1.8b5+
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.8verified1.8
Product: Core → SeaMonkey
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.