User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20130104 Firefox/20.0 Build ID: 20130104030823 Steps to reproduce: Launch Sandglaz "webapp". The background color for the splash image clashes with the icon of the app. Actual results: The background color should be the same as the color of the icon and it is not. Expected results: The background color should be the same as the color of the icon and it is not.

The icon is http://www.sandglaz.com/assets/logo_bg_transparent-ab793464aebdad0a8666921f566f1f21.png

(In reply to James Hugman from comment #1) > The icon is > http://www.sandglaz.com/assets/logo_bg_transparent- > ab793464aebdad0a8666921f566f1f21.png It's actually one of - http://www.sandglaz.com/assets/icon_128.png - http://www.sandglaz.com/assets/icon_48.png - http://www.sandglaz.com/assets/icon_16.png as per the manifest and marketplace listing.

I don't think we should be tracking bugs for A4A that are deemed nice to have.

Hmm.. the issue here is that we actually divide the number of unique "hues" we detect into 36 groups and bin the values inside them. Maybe we can keep the bins but create an average in them. i.e. between 0 and 36 the average hue was 24....

Thought you might enjoy looking at this lucas. This modifies our getDominantColor algorithm to maintain an "average" of the value seen in each bin. So if we see a hue value of 6 and another of 7, we store that the average in the 0-10 bin is 6.5. That alone doesn't fix this problem because I originally intentionally added some code to lighten the dominant color in the center of the splash screen, and darken it at the edges. I removed the lightening part here to make this icon match the splashscreen perfectly, but I'm not convinced we actually want to do that.

Any test build with this patch? Just curious of how it actually looks.

Here's a test build: http://people.mozilla.com/~wjohnston/colors.apk I don't really like removing the lightening/darkening from the background here. I'm going to reupload this patch with that bit removed (but it is in the apk above). It makes it really hard to see icons like the twitter icon. We need to come up with a system where webapps can tell us what they want for a splashscreen. I've been tempted to hijack some of the things apple has in place for that, but they are designed so specially to fit on particular iPhone screen sizes that its likely going to be hard to make them work here. MS also has some special metadata that is used for Win8 homescreen icons we could maybe look at....

This just adjusts the bins to pick better colors.

This helps fix up the 'lighten' and 'darken' code. We were using HSV colors before and changing the V part. This uses HSL instead, but since Android doesn't have any HSL code in its Color class, I had to write our own. There's a build with this fix at: http://people.mozilla.com/~wjohnston/colors2.apk screenshot coming. Asking for ibarlow input to make sure he sees this.

Screenshot of a variety of these splash screens with these patches.

In general I would suggest lightening the backgrounds by 20-30%. They look nice, but the colours are close enough to the foreground logo that they start to blend together. It's especially evident on the Twitter and Sandglaz screens. The Wikipedia one is also a bit... unfortunate. Any idea what's happening there?

(In reply to Ian Barlow (:ibarlow) from comment #11) > The Wikipedia one is also a bit... unfortunate. Any idea what's happening > there? Two things: 1.) The logo is all black and white. Our dominant color algorythm returns black in that case. And we can't really "darken" or "lighten" black, so we just get a solid color. Let me try tweaking things to not do that. Just return the color regardless, and then do a smarter job of lightening and darkening in those cases. 2.) I caught it mid transition, so the logo isn't entirely faded in at this point. I'll tweak the numbers and make a new image.

Wes, do you still want to review now? Or should I wait for these tweaks first?

Cleaning review flags for now.

Margaret made some improvements to this in bug 867249. I'd still like to get the nicer gradient in, but I'm not actively working on this.

(In reply to Wesley Johnston (:wesj) from comment #15) > Margaret made some improvements to this in bug 867249. I'd still like to get > the nicer gradient in, but I'm not actively working on this. Yes, my patches in bug 867249 made the first patch unnecessary. As for the second patch to add the gradient, I wonder if we could make it simpler by applying a color filter to a drawable with a white-to-gray gradient, similarly to how we create the darker border for favicons using a color filter.

Per bug 1235869, we're going to disable the Android web runtime, so we won't fix this bug in it. (This is part of a bulk resolution of bugs in the Firefox for Android::Web Apps component, from which I attempted to exclude bugs that are not specific to the runtime, but it's possible that I included one accidentally. If so, I'm sorry, and please reopen the bug!)