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




Tabbed Browser
13 years ago
5 years ago


(Reporter: Jon Henry, Unassigned)


Firefox Tracking Flags

(Not tracked)




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

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

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

Comment 2

13 years ago
*** Bug 262215 has been marked as a duplicate of this bug. ***
*** Bug 289155 has been marked as a duplicate of this bug. ***

Comment 4

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

Keep doing a good work and excuse me for this rant.
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → bookmarks
Assignee: vladimir → nobody
this seems to be fixed in Fx 3.1b1, no ?
why is this a bookmarks bug if the issue is the TAB BAR?
Component: Bookmarks & History → Tabbed Browser
QA Contact: bookmarks → tabbed.browser
I used the STR in comment #0 and cannot reproduce this bug with Nightly 21.
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.