Closed Bug 504645 Opened 11 years ago Closed 9 years ago
Stop shipping document
.png on Linux
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.
Whiteboard: [icon-namoroka] → [icon-namoroka][good first bug]
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?
Assignee: nobody → jwein
Status: NEW → ASSIGNED
Ah, indeed, bug 294375 removed this code.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 294375
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: Stop using document.png on Linux → Stop shipping document.png on Linux
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.
Attachment #540603 - Flags: review?(dolske)
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.
Attachment #540603 - Flags: review?(dolske) → review+
Err, "r+ with the following fixed". I thought Splinter put that at the bottom.
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
Attachment #541554 - Flags: review?(mark.finkle) → review+
Dolske, can you land this for me? Thanks!
9 years ago
Status: REOPENED → ASSIGNED
Whiteboard: [icon-namoroka][good first bug] → [inbound][icon-namoroka][good first bug]
Target Milestone: --- → Firefox 7
Status: ASSIGNED → RESOLVED
Closed: 9 years ago → 9 years ago
Hardware: x86 → All
Resolution: --- → FIXED
Whiteboard: [inbound][icon-namoroka][good first bug] → [icon-namoroka][good first bug]
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.
Status: RESOLVED → VERIFIED
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.
You need to log in before you can comment on or make changes to this bug.