Closed Bug 221704 Opened 21 years ago Closed 19 years ago

Show favicons in History sidebar

Categories

(Firefox :: Bookmarks & History, enhancement)

Product:
Firefox
Component:
Bookmarks & History
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: elektroschock, Assigned: bugzilla)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6a) Gecko/20031002 Firebird/0.7+
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6a) Gecko/20031002 Firebird/0.7+

Sites like prolinux.de have a own icon that is displayed in the URL line. So it
owuld be nice if the same icons also appear in the "history" menu.

Reproducible: Always

Steps to Reproduce:
1. Compare history bar appearence to URL edit or Tabs

Actual Results:  
Site-Icon not shown in history bar.
Chaning product to Firebird.
Bug for Mozilla suite is bug 113574.
Component: Browser-General → General
Product: Browser → Firebird
Version: Trunk → unspecified
.
Assignee: general → blake
dev review, I don't think we'll see this, but I've been wrong before.
Severity: trivial → enhancement
Status: UNCONFIRMED → NEW
Component: General → History
Ever confirmed: true
Summary: History does not use site icons → Show favicons in History sidebar
OS: Windows NT → All
QA Contact: general → mozilla
Hardware: PC → All
I think this should really enhance user experience and makes really easier to
search sites through the history. Proposing 1.0 blocking.
Flags: blocking1.0?
-ing will take patch
Flags: blocking1.0? → blocking1.0-
When I first found this bug I thought it would be a simple 2 minute fix, boy was
I was wrong. I learned a lot about mozilla in the process though.

I'm guessing the lowest-risk fix to this bug would involve duplicating the
not-insignificant amount of code added to the already complex bookmark.js (~1800
lines), and adding the plumbing for the history database. I think fixing it that
way would be repeating the mistakes of the Suite though.

This would be an extremely simple fix if the favicons were not stored in
bookmarks.html (bug 174265). The code for that fix would need only minor
modifications otherwise to work in the history sidebar. Technically it doesn't
matter, but making the history component dependant on the bookmark component
probably wouldn't fly. 

It's hard to believe something like this doesn't exist already, but I searched
and even knowing if it does exist is a bug...oi! (bug 12161). As of today's
nightly however, the bookmarks and history components  (those are the only
pieces I can speak to) respective data models leave quite a bit of room for
improvement. Using the data: url's, 500KB bookmark.html files are going to be
the norm soon ...what is that going to do to startup times?

Normalizing the internal datasources would lower memory and disk use, and bug's
like this wont have to be fixed twice. This could be done in the chrome even.

quick task list:
 - Create a new internal rdf datasource. Primary key would be url/port or
something I assume.
 - Starting with #icon start move all the many to one's into the new     
datasource. Using composite data sources would allow the change to happen
seamlessly.
 - Even if this bug gets fixed the old fashioned way, the new favicon code
should be moved out of bookmarks.js so the functions can be used elsewhere.

(In reply to comment #6)
> quick task list:
>  - Create a new internal rdf datasource. Primary key would be url/port or
> something I assume.
>  - Starting with #icon start move all the many to one's into the new     
> datasource. Using composite data sources would allow the change to happen
> seamlessly.
>  - Even if this bug gets fixed the old fashioned way, the new favicon code
> should be moved out of bookmarks.js so the functions can be used elsewhere.

This might be easier than you think -- creating a new global in-memory-ds for
icons and aggregating it with the bookmarks and history ds's using the proxy
aggregation stuff (bug 235665) is definitely the right way to go.  The bookmarks
loader can just know to stick Icon resources in that DS rather than its own.

I'm not really happy with data: URLs though, as I'd rather store the data as a
binary blob somewhere that can get referenced in an image directly.  As you say,
bookmarks.html is getting somewhat silly (though its effect on loading times
should be negligible), and I'd hate to have to keep a data URL around for tons
of sites for history.  I'm not sure how you could expire the icons, and also I'm
not sure if it's worth serializing non-bookmarked history favicons to disk.

Ah, looks like you guys are 20 steps ahead of me. 

Should this bug depend on bug 235665 then? It's definitely not the only way to
fix this, but aggregation seems by far the cleanest way and it's +1.0 anyway. 
The web metadata Ben referred to in that bug seems to be the global normalized
datasource I was looking for. Does it have a name or bug entry?
Blocks: 262161
No longer blocks: 262161
needs aviary landing keyword
why would it need that keyword
(In reply to comment #7)

>                  I'm not sure how you could expire the icons, and also I'm
> not sure if it's worth serializing non-bookmarked history favicons to disk.

The favicons are already stored in the cache, so they can be used as long as
they stay cached. The oldest favicons would disappear naturaly.
And the favicons of the bookmarked sites, which are permanently stored, could be
used for these sites.
So, unlike IE which shows the favicons in the history only for the bookmarked
sites, the recently visited (or frequently but not bookmarked) sites would have
a favicon too.
Bug 317839 introduced a new favicon service for the new bookmarks and history ("places") systems which stores favicons for history. You currently (Feb 2006) need to --enable-places to get this.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
(In reply to comment #12)
> Bug 317839 introduced a new favicon service for the new bookmarks and history
> ("places") systems which stores favicons for history. You currently (Feb 2006)
> need to --enable-places to get this.
> 

This is true on the newer versions, but what about the 1.5.0.x branch? There is at least one other similar bug still open for this very reason.
I was just unvoting myself from a bunch of old bugs, and checked this one. 

At some point, this one regressed. There are no favicons on the history sidebar with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061025 BonEcho/2.0 ID:2006102503


This bug should be reopened and have regression put in the key words field.
Flags: blocking1.8.1.1?
(In reply to comment #14)
> I was just unvoting myself from a bunch of old bugs, and checked this one. 
> 
> At some point, this one regressed. There are no favicons on the history sidebar
> with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061025
> BonEcho/2.0 ID:2006102503
> 
> 
> This bug should be reopened and have regression put in the key words field.

This bug is irrelevant as Firefox 3 will have places as a mean to access history, so there is no reason to fix a piece of UI that won't appear in Firefox 3.


(In reply to comment #15)
> (In reply to comment #14)
> > I was just unvoting myself from a bunch of old bugs, and checked this one. 
> > 
> > At some point, this one regressed. There are no favicons on the history sidebar
> > with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061025
> > BonEcho/2.0 ID:2006102503
> > 
> > 
> > This bug should be reopened and have regression put in the key words field.
> 
> This bug is irrelevant as Firefox 3 will have places as a mean to access
> history, so there is no reason to fix a piece of UI that won't appear in
> Firefox 3.

In the "Version" field, it says "unspecified", so I would think that it then applies to any version. Should Version be changed to "Trunk" then?


Doesn't meet the criteria for security releases.

Having some trouble reconciling the "FIXED" state with the lack of patches.
Flags: blocking1.8.1.1? → blocking1.8.1.1-
Marking as dupe isn't either a good thing in this case.
I think that there should be "Fixed by bug #XXXXXX".
(In reply to comment #17)
> Doesn't meet the criteria for security releases.
> 
> Having some trouble reconciling the "FIXED" state with the lack of patches.

So, is it or isn't it?
Component: History → Bookmarks & History
QA Contact: mozilla → bookmarks
You need to log in before you can comment on or make changes to this bug.