Stop shipping document.png on Linux

VERIFIED FIXED in Firefox 7

Status

()

Firefox
General
VERIFIED FIXED
8 years ago
6 years ago

People

(Reporter: Dolske, Assigned: jaws)

Tracking

Trunk
Firefox 7
All
Linux
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [icon-namoroka][good first bug])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

8 years ago
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.
Whiteboard: [icon-namoroka]

Comment 1

8 years ago
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.
(Reporter)

Updated

6 years ago
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
(Reporter)

Comment 3

6 years ago
Ah, indeed, bug 294375 removed this code.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 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.
(Reporter)

Comment 6

6 years ago
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
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.
Attachment #540603 - Flags: review?(dolske)
Try submission: http://tbpl.mozilla.org/?tree=Try&rev=8d30e2b3c7c3
(Reporter)

Comment 9

6 years ago
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+
(Reporter)

Comment 10

6 years ago
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.
Attachment #540603 - Attachment is obsolete: true
Attachment #541554 - Flags: review?(dolske)
(Reporter)

Comment 12

6 years ago
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.
Attachment #541554 - Flags: review?(mark.finkle)
Attachment #541554 - Flags: review?(dolske)
Attachment #541554 - Flags: review+
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!
Status: REOPENED → ASSIGNED
(Reporter)

Updated

6 years ago
Keywords: checkin-needed
http://hg.mozilla.org/integration/mozilla-inbound/rev/898a771d5825
Keywords: checkin-needed
Whiteboard: [icon-namoroka][good first bug] → [inbound][icon-namoroka][good first bug]
Target Milestone: --- → Firefox 7

Updated

6 years ago
Flags: in-testsuite-
Merged:
http://hg.mozilla.org/mozilla-central/rev/898a771d5825
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago6 years ago
Hardware: x86 → All
Resolution: --- → FIXED
Whiteboard: [inbound][icon-namoroka][good first bug] → [icon-namoroka][good first bug]

Comment 17

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.
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.
Blocks: 705974
You need to log in before you can comment on or make changes to this bug.