Spun off from bug 499226, where we were removing unneeded branding images from Linux. Turns out document.png was still being used. See: browser/components/shell/src/nsGNOMEShellService.cpp#288, where it copies document.png to ~/.icons/firefox-document.png when you trigger the "set default browser" code. This seems kinda crappy, since it means icon updates should repeat the copy or the user has the old version floating around. I'm not even sure this is the right thing to be doing.
This doesn't even do anything. MIME icons for common types like HTML are provided by the GTK theme, not each application. It should be safe to just remove that code.
I ran a search on MXR and could only find references to a "document.png" within Makefiles. There is a reference to a "firefox-document.png" in browser/components/shell/src/nsGNOMEShellService.cpp#98 but it seems that the variable, |kDocumentIconPath|, is defined but never referenced. Could this have been fixed already?
Ah, indeed, bug 294375 removed this code.
Should we stop shipping the actual image then? People might depend on us shipping it somehow, I guess, but I'm not sure we should let that stop us.
In reply to comment #4: If it's not being used, then I think we should stop shipping it. This gives us an opportunity to decrease the filesize of our initial download (albeit by a tiny bit) but every little step counts.
Hmm, yeah, I wasn't thinking. We should nuke the icon from Hg and the bits that ship it.
Created attachment 540603 [details] [diff] [review] Patch for bug 504645 Removed document.png from source control and updated the Makefiles to not copy the file anymore. Also updated XULRunner to remove document.png, but I'm not sure if we wanted that.
Try submission: http://tbpl.mozilla.org/?tree=Try&rev=8d30e2b3c7c3
Comment on attachment 540603 [details] [diff] [review] Patch for bug 504645 Review of attachment 540603 [details] [diff] [review]: ----------------------------------------------------------------- r+ with the above fixed. ::: xulrunner/app/Makefile.in @@ +189,1 @@ > $(NULL) Since ICON_FILES is empty now, you should go ahead and remove the immediately-following libs:: and install:: targets that now have nothing to do. Might be a good idea to do a quick xulrunner build just to make sure nothing blows up.
Err, "r+ with the following fixed". I thought Splinter put that at the bottom.
Created attachment 541554 [details] [diff] [review] Patch for bug 504645 - version 2 I have made the changes requested. I also built xulrunner but had issues running |make package| from within the objdir. This was the error that I encountered: sed: can't read components/components.manifest: No such file or directory There doesn't appear to be a "components" directory.
Comment on attachment 541554 [details] [diff] [review] Patch for bug 504645 - version 2 That's ok, I don't think that build thing matters. Bouncing over to mfinkle for a rubberstamp on the xulrunner change, but it looks fine to me.
Comment on attachment 541554 [details] [diff] [review] Patch for bug 504645 - version 2 no downsides come to mind
Dolske, can you land this for me? Thanks!
6 years ago
Mozilla/5.0 (X11; Linux i686; rv:7.0a1) Gecko/20110627 Firefox/7.0a1 document.png no longer present in branding directories. Setting status to Verified Fixed.
For the future, please add any deprecated files to browser/installer/removed-files.in, so that users updating have them removed too. Fixing that for this bug in bug 705974.