only show favicons in the url bar results if browser.chrome.site_icons is true
12 years ago
Depends on: 373353
when the pref is false, we'd want to pass in EmptyString() as the image when calling AppendMatch() in nsNavHistory.cpp Additionally, to avoid a 16px x 16px blank spot, we need to pass EmptyString() as the (instead of "favicon") as the style when calling AppendMatch() in nsNavHistory.cpp As an optimization, when the pref is false, we also don't need to do the JOIN with the moz_favicons table in nsNavHistory::CreateAutoCompleteQuery()
Question from a QA standpoint: If we flip that pref mid-stream (say we've already got favicons populating both the URL bar's autocomplete dropdown as well as the Bookmarks Toolbar), would the behavior be to: 1. Just stop propagating new favicons? or 2. Remove the already existing ones? I'd imagine the former, but I'm writing the Litmus testcase, so I wanted to be sure.
12 years ago
Duplicate of this bug: 389075
This WFM as option 1 above. After the config flip off, favicons from new sites visited are not shown in the URL bar nor in the autocomplete, they get the default blank paper icon. Pages with existing favicons don't show that favicon in the URL bar on page load, but the favicons do show up in autocomplete. That seems inconsistent. Option 2 seems to be the correct method here. Show no favicon if the config is false. Should this be WFM, WONTFIX or does work need to be done here?
removing in-litmus? until this is resolved, feel free to add it back at that time.
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.