canmove, Confirmed users
640
edits
No edit summary |
|||
Line 82: | Line 82: | ||
#Create empty favicon entry with <code>id</code> and <code>guid</code>. | #Create empty favicon entry with <code>id</code> and <code>guid</code>. | ||
#Refer to favicon id in the <code>moz_places</code> entry. | #Refer to favicon id in the <code>moz_places</code> entry. | ||
=== More detailed plan === | |||
I propose a staged implementation, given dependencies on Places changes. Something a little like this: | |||
# Extend bookmarks and history engines to track faviconURI. We do this instead of GUID as a trivial proof of concept, rather than waiting around. | |||
# Implement favicon engine to sync favicons keyed by URI. | |||
# Implement observers for nsINavHistoryObserver::onPageChanged/nsINavHistoryObserver::ATTRIBUTE_FAVICON to track bookmark/history changes on favicon alteration, and also poke the favicon tracker to ensure that changed favicons get synced up. | |||
# Implement GUIDs for favicons, in line with the Places plan. | |||
# Rejig favicon and other engines to use the GUID instead of the URI. This will, of course, be a breaking change (and we don't want to use URIs in production for privacy reasons), so this will be the first point at which this can be a user-facing feature. | |||
# Reimplement bookmarks and favicons engines using async repository API. | |||
# Switch to using mozIAsyncFavicons instead of nsIFaviconService. | |||
== Questions == | == Questions == |