Created attachment 320105 [details] [diff] [review] patch - v1 (backed out) Until bug 429721 came along, the favicon for the netError pages was the same for all platforms. Now, it can be customized fairly easily. Do that for Tango.
The docs need to be updated if this lands. See bug 430792 comment 22, 24 and 26. I wonder if it would be better to use a redirect rule to use moz-icon://stock/gtk-dialog-warning?size=menu instead of chrome://global/skin/icons/warning-16.png in the manifest file for gnomestripe?
Comment on attachment 320105 [details] [diff] [review] patch - v1 (backed out) r=me for the places bit
Comment on attachment 320105 [details] [diff] [review] patch - v1 (backed out) Replaces another use of a Windows icon with a GTK stock icon.
Checking in docshell/resources/content/jar.mn; /cvsroot/mozilla/docshell/resources/content/jar.mn,v <-- jar.mn new revision: 1.3; previous revision: 1.2 done Checking in docshell/resources/content/netError.xhtml; /cvsroot/mozilla/docshell/resources/content/netError.xhtml,v <-- netError.xhtml new revision: 1.33; previous revision: 1.32 done Seems I accidentally landed the toolkit part of this last night at 2008-05-09 00:25. I'll file a bug to get the commit message fixed. :(
Backed out per schrep/beltzner, to fix 433241. mozilla/docshell/resources/content/jar.mn 1.4 mozilla/docshell/resources/content/netError.xhtml 1.34 mozilla/toolkit/components/places/src/nsFaviconService.h 1.13
Created attachment 343834 [details] [diff] [review] patch - v2 Same as v1 but adds Kai Liu's fix in bug 433241 to deal with the regression it caused. Carrying over review for v1, and just asking for review on Kai's part.
Out of curiosity, could we not do a chrome override for that image in the linux theme? If it works, this is a really simple patch that doesn't touch code everywhere else... override chrome://global/skin/icons/warning-16.png moz-icon://stock/gtk-dialog-warning?size=menu
I seem to remember that chrome overrides wouldn't work with moz-icon, insisting it was not a local file. I have no idea in which bug I discovered that though
Is moz-icon ever not a local file? It seems like that's the cleaner/better solution here.
I don't see anything in the chrome registry code which would cause that to fail, after a quick look. Worth a try!
With the override suggestion, it gets no favicon. Investigating why...
It does, in fact, fail a security check: WARNING: Remote chrome not allowed! Only file:, resource:, jar:, and cached chrome channels are valid. : file /home/sdwilsh/central/chrome/src/nsChromeProtocolHandler.cpp, line 582 Looking into if we can make an exception for moz-icon stuff...
Created attachment 349894 [details] screenshot Got this working with the patch in bug 466582 the patch I'm about to upload.
Created attachment 349896 [details] [diff] [review] v3.0
Comment on attachment 349896 [details] [diff] [review] v3.0 a191=beltzner
http://hg.mozilla.org/mozilla-central/rev/3744204c1576 This cannot land on branch until the dependent bug lands there.
I had to back this out because the dependent bug got backed out.
(In reply to comment #11) > I don't see anything in the chrome registry code which would cause that to > fail, after a quick look. Worth a try! Rather conveniently, *stripe doesn't count as a theme, and is therefore allowed to do chrome overrides, unlike 3rd party themes...