258461 - Canceling page load results in incorrect favicon displaying on the tab bar

Status: RESOLVED WORKSFORME

(Firefox :: Tabbed Browser, defect)

Description

[Jon Henry]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040907 Firefox/1.0 PR (NOT FINAL)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040907 Firefox/1.0 PR (NOT FINAL)

This appears to only affect the tab bar, not the location bar or anywhere else
favicons are displayed. It also looks like it *has* to be a link from the
personal toolbar, not a url you type in or even one from the normal bookmarks menu.

This isn't a huge deal, but it definitely makes tabbed browsing a little
confusing when you get a lot of tabs open and want to quickly ID them by the
favicon.

Reproducible: Always
Steps to Reproduce:
1. Have a page open and the tab bar visible.
2. Click a link on your personal toolbar that has a favicon associated with it.
3. Quickly press escape to cancel the page load.

Actual Results:  
The favicon displayed on the tab bar is the icon of the site you canceled
loading, not the current page's.

Expected Results:  
Revert to the favicon associated with the current site.

Comment 1

[Ryan Polk (Quark)]

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

Comment 2

[Martin Poirier]

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

Comment 3

[:Gavin Sharp [email: [e-mail]]]

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

Comment 4

[Miguel Gaspar]

If the user leaves the the current page,any chenge pertaining to the new page
should be consistent: displaying the new uri i the address bar, switching the
icons, etc., should be done after the current page is no longer beeing
displayed. In the interim, there should be indication that an new page is beeing
loaded, not the currently visible one. If the user aborts the loading, he should
be left either
- with the previous page and all pertaining info (address bar, favicon, etc.)
- or an empty or partial new page, if something has been fetched that can be
rendered, BUT with a clear indication that it has been interrupted!

If, and only if, the behavior I propose is deemed correct, I dare ask: Is this
too hard for such great developers to fix? Perhaps it isn't a top priority, but
I think it does matter, and I guess it wouldn't take someone who understands the
codebase much more than a few hours to get this right... or is the code SO much
bloated? Is this a spaghetti-like thing that no-one understands?

Now, if fixing things in Mozilla isn't a thing for super-human beeings, if the
mozilla codebase has some rationale, if it's just a matter of people having too
much bugs to solve and too little time, I guess a few tips on where to look
would allow me to take on this particular bug and contribute in a more positive
way - I do have a knowledge of C programming, just don't know where to start
hunting.

Keep doing a good work and excuse me for this rant.

Comment 5

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change

Comment 6

[Nicolas Mandil (:NicolasWeb)]

this seems to be fixed in Fx 3.1b1, no ?

Comment 7

[Marco Bonardo [:mak]]

why is this a bookmarks bug if the issue is the TAB BAR?

Comment 8

[Jared Wein [:jaws] (please needinfo? me)]

I used the STR in comment #0 and cannot reproduce this bug with Nightly 21.