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.
*** Bug 258462 has been marked as a duplicate of this bug. ***
*** Bug 262215 has been marked as a duplicate of this bug. ***
*** Bug 289155 has been marked as a duplicate of this bug. ***
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.
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
this seems to be fixed in Fx 3.1b1, no ?
why is this a bookmarks bug if the issue is the TAB BAR?
I used the STR in comment #0 and cannot reproduce this bug with Nightly 21.