Closed
Bug 745999
Opened 12 years ago
Closed 12 years ago
[10.5] Web Apps Missing Icon in Applications Directory
Categories
(Firefox Graveyard :: Web Apps, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: marcia, Unassigned)
References
Details
Attachments
(1 file)
20.92 KB,
image/png
|
Details |
Seen while running the try build from ftp://ftp.mozilla.org/pub/firefox/try-builds/myk@mozilla.com-1bbb79853e99/ STR: 1. Download the macosx64 build from the above directory. 2. Launch with a new profile 3. Go to https://apps.mozillalabs.com/appdir/ and pick an app to install. 4. Download the app 5. Notice in the attached screenshot that the app icon is missing This does not happen in 10.6 and 10.7 using the same build.
Comment 1•12 years ago
|
||
plist issue may fix this bug? Depend on bug 747601?
Updated•12 years ago
|
Whiteboard: [marketplace-beta-]
Comment 2•12 years ago
|
||
yeah, please try with latest nightly now that a patch for bug 747601 landed
Depends on: 747601
Comment 3•12 years ago
|
||
Note - This is not fixed on the current nightly build.
Comment 4•12 years ago
|
||
Re-tested with today's nightly build - This issue still happens on OS X 10.5.
Updated•12 years ago
|
blocking-kilimanjaro: --- → +
Comment 5•12 years ago
|
||
Problem code area is in resource:///modules/WebappsInstaller.jsm: process.run(true, ["-s", "format", "icns", aIcon.path, "--out", this.iconFile.path, "-z", "128", "128"], 9); Executing this manually we saw this: host-7-218:TemporaryItems mozilla$ /usr/bin/sips -s format icns tmpicon-1.png --out test.icns -z 128 128 /Users/mozilla/Library/Caches/TemporaryItems/tmpicon-1.png Error: Unsupported output format com.apple.icns /Users/mozilla/Library/Caches/TemporaryItems/test.icns
Comment 6•12 years ago
|
||
Possible idea? https://github.com/landonf/simlaunch/commit/884f4bba5bf012636fb1902830ffa5efe2295a68
Comment 7•12 years ago
|
||
Dan, what do we need to do differently on Mac OS X 10.5 to resolve this issue?
Comment 8•12 years ago
|
||
As an extension to comment 5, we discovered that the appicon.icns file is not getting written in Contents/Resources.
Comment 9•12 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #6) > Possible idea? > > https://github.com/landonf/simlaunch/commit/ > 884f4bba5bf012636fb1902830ffa5efe2295a68 That was a good idea, but I just checked in a 10.5 machine and ImageMagick is not available there either. The options we have as I see it: - write the icon by ourselves. according to wikipedia the icon format doesn't seem very complicated. Apparently .icns is just a container so we don't need to get gfx to write an encoder, we just need a .png in the proper size and write the headers around it - ask app developers to provide a .icns icon - ship a third-party conversion library. There's a project called libicns licensed under the GPL
Comment 10•12 years ago
|
||
(In reply to Felipe Gomes (:felipe) from comment #9) > (In reply to Jason Smith [:jsmith] from comment #6) > > Possible idea? > > > > https://github.com/landonf/simlaunch/commit/ > > 884f4bba5bf012636fb1902830ffa5efe2295a68 > > That was a good idea, but I just checked in a 10.5 machine and ImageMagick > is not available there either. > > The options we have as I see it: > - write the icon by ourselves. according to wikipedia the icon format > doesn't seem very complicated. Apparently .icns is just a container so we > don't need to get gfx to write an encoder, we just need a .png in the proper > size and write the headers around it > - ask app developers to provide a .icns icon > - ship a third-party conversion library. There's a project called libicns > licensed under the GPL The second option probably isn't going to work, as app developers commonly have been choosing to use PNG files, as shown by the developer docs they see and use.
Comment 11•12 years ago
|
||
I've found another MIT license, third-party icns conversion library called makeicns. We could include it for older Macs, and phase it out when we drop support for 10.5. https://bitbucket.org/mkae/makeicns
Comment 12•12 years ago
|
||
Note that we can't integrate GPL-licensed code into Mozilla codebases, although we can integrate MIT-licensed code (cc:ing Gerv for confirmation).
Comment 13•12 years ago
|
||
As Myk says; integrating GPLed code would require us to ship the entire app under the GPL, which we do not wish to do. MIT-licensed code is fine. When you import it, you need to read the text and do what is says; there may be a requirement to display the license text in your equivalent of about:license. Gerv
Comment 14•12 years ago
|
||
Asa - How many users do we have on OS X 10.5? How important is adding this support on OS X 10.5?
Updated•12 years ago
|
blocking-kilimanjaro: + → ?
Target Milestone: --- → Firefox 15
Updated•12 years ago
|
Priority: -- → P3
Comment 15•12 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #14) > Asa - How many users do we have on OS X 10.5? How important is adding this > support on OS X 10.5? We have about as many 10.5 users as 10.7 users.
Comment 16•12 years ago
|
||
(In reply to Asa Dotzler [:asa] from comment #15) > (In reply to Jason Smith [:jsmith] from comment #14) > > Asa - How many users do we have on OS X 10.5? How important is adding this > > support on OS X 10.5? > > We have about as many 10.5 users as 10.7 users. Hmm. That could alter the reality of the priority of this then (it's currently set as a nice to have). Juan mentioned that there was mention of OS X 10.5 support being cut soon, although the user base amount could affect this decision. In the k9o meeting (this bug got re-nomed to be re-analyzed due to the proceeding rationale), let's figure this out, as the underlying priority is affected by this.
Updated•12 years ago
|
Whiteboard: [marketplace-beta-]
Comment 17•12 years ago
|
||
Per comment 16 - Reseting the priority of this bug to have it re-triaged.
Priority: P3 → --
Comment 18•12 years ago
|
||
This should follow whatever the desktop lead is on 10.5. Asa, can you answer this?
Updated•12 years ago
|
Priority: -- → P2
Comment 19•12 years ago
|
||
- for k9o as this doesn't read like a blocker and 10.5 support will likely go away soonish.
blocking-kilimanjaro: ? → -
Comment 20•12 years ago
|
||
(In reply to Lawrence Mandel [:lmandel] from comment #19) > - for k9o as this doesn't read like a blocker and 10.5 support will likely > go away soonish. I don't think this addresses the user base concern - Asa mentioned that the number of users on 10.7 are the same as 10.5 in comment 15. Not having an icon for an app is a pretty basic part of the native web apps flow for firefox. This brings into question whether it is safe to cut 10.5 support. Asa - Can you please clarify? Is it really safe to cut support here? Re-nominating, as this needs product input.
blocking-kilimanjaro: - → ?
Comment 21•12 years ago
|
||
Chris - Based on how many users are using 10.5 on the metrics dashboard, is it safe to cut support for 10.5? Or should we re-think that?
Comment 22•12 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #20) > I don't think this addresses the user base concern - Asa mentioned that the > number of users on 10.7 are the same as 10.5 in comment 15. Not having an > icon for an app is a pretty basic part of the native web apps flow for > firefox. This brings into question whether it is safe to cut 10.5 support. > Asa - Can you please clarify? Is it really safe to cut support here? Let's not morph this bug into a discussion of when Mozilla should stop supporting Mac OS X 10.5, as that is very much off-topic. The question at hand is whether the issue reported in this bug rises to the level of a K9O blocker. Another way of asking that question is: if every other K9O blocker was fixed, and this was the only one that remained, would you continue to hold K9O hostage to this bug? Asked that way, the answer is obviously no. Webapps work just fine with generic icons, and although such icons are a stain on the polish of the feature, and users are apt to be disconcerted by them, the user-experience cost is not bad enough to justify blocking K9O, regardless of whether or not K9O supports Mac OS X 10.5. (For that matter, it also isn't bad enough to justify blocking the initial release of the webapps feature of Firefox, which is why its drivers, including you, triaged this as a non-blocking P2 for Firefox 15.) Note: although no single such bug will block K9O, it's possible that a large number of such bugs, in toto, would be considered block-worthy, because, taken together, they cause K9O products and features to feel too rough and unfinished. That isn't accounted for by the current triage process, which would need to mark such bugs as wanted, nice-to-have, polish, catfood, and the like so K9O drivers can keep track of them. But that's no justification for making this block.
Comment 23•12 years ago
|
||
(In reply to Myk Melez [:myk] [@mykmelez] from comment #22) > (In reply to Jason Smith [:jsmith] from comment #20) > > I don't think this addresses the user base concern - Asa mentioned that the > > number of users on 10.7 are the same as 10.5 in comment 15. Not having an > > icon for an app is a pretty basic part of the native web apps flow for > > firefox. This brings into question whether it is safe to cut 10.5 support. > > Asa - Can you please clarify? Is it really safe to cut support here? > > Let's not morph this bug into a discussion of when Mozilla should stop > supporting Mac OS X 10.5, as that is very much off-topic. The question at > hand is whether the issue reported in this bug rises to the level of a K9O > blocker. It's important to know here in this bug specifically because it affects whether we support it or not (the OS decision is critical to understand). > > Another way of asking that question is: if every other K9O blocker was > fixed, and this was the only one that remained, would you continue to hold > K9O hostage to this bug? > > Asked that way, the answer is obviously no. Webapps work just fine with > generic icons, and although such icons are a stain on the polish of the > feature, and users are apt to be disconcerted by them, the user-experience > cost is not bad enough to justify blocking K9O, regardless of whether or not > K9O supports Mac OS X 10.5. It takes away the brand of the actual application itself from the user's perspective - icons are more representative of a brand than the text itself. Yes the apps infrastructure remains functional, but the cost of not showing an icon to the user takes away the brand connection. Like I said above - all I'm asking for is data about the OS X 10.5 user base (% of users affected). If it's low, then we can drop this. If it's higher, then this gets put more into question. > > (For that matter, it also isn't bad enough to justify blocking the initial > release of the webapps feature of Firefox, which is why its drivers, > including you, triaged this as a non-blocking P2 for Firefox 15.) The P2 declaration is inconclusive at this point - a user base of who's affected would make that distinction along with the severity. Remember, an icon feature is on the critical path to a user using webapps in firefox - so a user on 10.5 would hit this and note this as a problem (we'd get attacked for not supporting this, loudly in the support forums). The question is how many users will hit this and whether in FF 15, we are declaring 10.5 complete support or not. > > Note: although no single such bug will block K9O, it's possible that a large > number of such bugs, in toto, would be considered block-worthy, because, > taken together, they cause K9O products and features to feel too rough and > unfinished. > > That isn't accounted for by the current triage process, which would need to > mark such bugs as wanted, nice-to-have, polish, catfood, and the like so K9O > drivers can keep track of them. But that's no justification for making this > block. The OS support concern is why I'm questioning if this should block or not. All I'm asking for is the data, then we can make a decision on this (it's on the metrics dashboards somewhere, just need to look it up). I'd feel a lot better if we had data to back this decision up.
Comment 24•12 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #23) > It's important to know here in this bug specifically because it affects > whether we support it or not (the OS decision is critical to understand). It might be important to know what folks *conclude* about 10.5 support in this bug, but the *discussion* about 10.5 support should happen elsewhere. > Like I said above - all > I'm asking for is data about the OS X 10.5 user base (% of users affected). Asa already provided that information in comment 15, and it was available to K9O drivers when they made the decision that this doesn't block K9O. > The P2 declaration is inconclusive at this point - a user base of who's > affected would make that distinction along with the severity. We know who's affected. It's 50% of N% of Firefox users (where N is the single-digit percent of users on Mac). > (we'd get attacked for not supporting this, loudly in the support forums). That's irrelevant. because we shouldn't make decisions based on whether or not we'll be attacked for them. > The OS support concern is why I'm questioning if this should block or not. > All I'm asking for is the data, then we can make a decision on this (it's on > the metrics dashboards somewhere, just need to look it up). I'd feel a lot > better if we had data to back this decision up. Gavin cited OS support in his comment, but it wasn't the only consideration for the K9O drivers who decided that this didn't block. The even more relevant one is that the issue here, while real and valid, does not rise to the level of a blocker, even if we support 10.5 at the time of the K9O event.
Comment 25•12 years ago
|
||
Just because this doesn't block Kilimanjaro doesn't mean that it can't or won't be fixed. This bug is simply not release defining. It is not required to realize the vision of the Web as the platform as defined in the product requirements. To Myk's point about bugs that fall into the category "wanted" for various reasons, I think each team will be able to make the call as to what they can reasonably fix to improve their respective deliverable after they address their k9o blockers. We have not discussed this type of tracking and should. I will bring this up outside of this bug.
Comment 26•12 years ago
|
||
(In reply to Myk Melez [:myk] [@mykmelez] from comment #24) > > Like I said above - all > > I'm asking for is data about the OS X 10.5 user base (% of users affected). > > Asa already provided that information in comment 15, and it was available to > K9O drivers when they made the decision that this doesn't block K9O. > I'm looking for physical numbers here. We originally declared that we were supporting OS X 10.5 - this bug falls under smoke tests, so breaking this is a serious problem in terms of the brand loyalty concerns. > > > The P2 declaration is inconclusive at this point - a user base of who's > > affected would make that distinction along with the severity. > > We know who's affected. It's 50% of N% of Firefox users (where N is the > single-digit percent of users on Mac). I don't follow. I want the physical numbers here. What I want is an answer to the following question: Of all of the firefox users that are currently have desktop firefox installed, what percentage of users have firefox installed on an OS X 10.5 machine? Looking for an answer of the term of: X% of firefox installs are on OS X 10.5 > > > > (we'd get attacked for not supporting this, loudly in the support forums). > > That's irrelevant. because we shouldn't make decisions based on whether or > not we'll be attacked for them. I'd argue it is relevant. It's similar to if you had an annoying error message that a user would hit at a high rate (>75%) - Users will pick up on it, complain repeatedly that something isn't working, and as a result, creating a support headache if we said publicly that we support OS X 10.5. If we are going to make this a non-blocker, then we need to be careful on our wording when we publicize this feature (i.e. saying we have full support for web apps on 10.6+, limited support on 10.5). An incorrect presentation of this will result in the exact situation we ended up with lack of support of linux on webapps (aka bad PR). > > > > The OS support concern is why I'm questioning if this should block or not. > > All I'm asking for is the data, then we can make a decision on this (it's on > > the metrics dashboards somewhere, just need to look it up). I'd feel a lot > > better if we had data to back this decision up. > > Gavin cited OS support in his comment, but it wasn't the only consideration > for the K9O drivers who decided that this didn't block. The even more > relevant one is that the issue here, while real and valid, does not rise to > the level of a blocker, even if we support 10.5 at the time of the K9O event. I disagree. Lack of support for enabling brand loyalty could really hurt our partners perspective of our product (their brand icon can't be used in the app itself). At this point, I'm looking for BD and userbase input at this point. They would be the right people to make this call (not meaning to attack here on gavin's insight, but I just think brand loyalty is a touchy area for getting partners on board with our infrastructure).
Comment 27•12 years ago
|
||
86 million users overall 0.8 million on OS X 10.5 0.9% overall 17% of OS X users are on OS X 10.5 https://metrics.mozilla.com/pentaho/content/pentaho-cdf-dd/Render?solution=metrics&path=blocklist/aduBreakdownByOs&file=aduBreakdownByOs.wcdf
Comment 28•12 years ago
|
||
Note - The numbers in comment 27 are rough numbers, not exact numbers.
Comment 29•12 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #26) > An incorrect presentation > of this will result in the exact situation we ended up with lack of support > of linux on webapps (aka bad PR). But that's about how we present the decision, not what decision we make. And the Linux case is especially illustrative of how we shouldn't make decisions based on whether or not we'll be attacked for them, since we made the correct decision not to work on Linux support, even though doing so caused Linux users to complain. > I disagree. Lack of support for enabling brand loyalty could really hurt our > partners perspective of our product (their brand icon can't be used in the > app itself). I don't follow this argument, especially that last bit, since partners can use their brand icons in their apps to their hearts' content. But in any case we've filled this bug enough with additional arguments for and against blocking K9O on it. Time for drivers to retriage. > At this point, I'm looking for BD and userbase input at this point. They > would be the right people to make this call (not meaning to attack here on > gavin's insight, but I just think brand loyalty is a touchy area for getting > partners on board with our infrastructure). BD and user input is certainly welcome, but K9O drivers are the right people to make the call. By definition. That's the whole point of having drivers.
Updated•12 years ago
|
blocking-kilimanjaro: ? → ---
Updated•12 years ago
|
Target Milestone: Firefox 15 → ---
Updated•12 years ago
|
QA Contact: jsmith
Comment 30•12 years ago
|
||
Marking for re-triage. Requesting to won't fix. We're removing support for OS X 10.5 in FF 17 and on from what I understand. If we don't plan to fix this in FF 16, then this sounds like a won't fix.
Priority: P2 → --
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Assignee | ||
Updated•8 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•