438713 - Make "Advanced" dropdown tab blend in with the Search textfield's background

Status: VERIFIED FIXED

(addons.mozilla.org Graveyard :: Public Pages, defect)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Screenshot of the "Advanced" tab

Spinning this off from bug 436952, because it's better but still needs to be fixed.

In its default, collapsed mode, the "Advanced" dropdown tab still doesn't blend in with the background of the Search textfield.

See way-zoomed screenshot; this is noticeable too when not zoomed, however.

Comment 1

[Fred Wenzel [:wenzel]]

I can't believe this has been sitting around for so long. I'll pull this into 4.0.4, because I am sure it is secretly killing puppies when nobody's looking, and for the sake of humanity in general.

Comment 2

[Fred Wenzel [:wenzel]]

Attachment: new sprite.png

I fixed this very easily in the attached PNG file.

However, when I change the original PSD file with GIMP, the resulting PNG file ends up being 150k (after pngcrush) as opposed to the current about 20k. I think Photoshop does something fancy with the file on export that I am missing here. Ryan, do you have any ideas?

Comment 3

[Ryan Doherty (:rdoherty)]

Comment on attachment 349687 [details]
new sprite.png

I'm confused. You say the file is 150k, but the one attached is 15k. Is it the correct file?

Comment 4

[Fred Wenzel [:wenzel]]

(In reply to comment #3)
> (From update of attachment 349687 [details])
> I'm confused. You say the file is 150k, but the one attached is 15k. Is it the
> correct file?

Yes, two different issues: By directly editing the PNG file, I get a reasonably small file (attached) that fixes this bug's issue.

My second question was, do we want to edit the original PSD file instead? In that case, I have trouble exporting it to PNG with a small file size.

Comment 5

[Brian Krausz]

(In reply to comment #2)
> Created an attachment (id=349687) [details]
> new sprite.png
> 
> I fixed this very easily in the attached PNG file.
> 
> However, when I change the original PSD file with GIMP, the resulting PNG file
> ends up being 150k (after pngcrush) as opposed to the current about 20k. I
> think Photoshop does something fancy with the file on export that I am missing
> here. Ryan, do you have any ideas?

This was one of the problems with Gimp I had, Photoshop seems a lot friendlier (though I don't know why pngcrush isn't helping).  Are you exporting as PNG-24 or PNG-8?  I think 8 was what I used.  Worst case, can you attach the PSD and I'll futz with it in Photoshop?

Comment 6

[Fred Wenzel [:wenzel]]

Attachment: Color profile confusion?

Ah-hah! As PNG8, the size shrinks to about 30k.

However, Brian, can you please open the original psd file (I put it at: http://people.mozilla.com/~fwenzel/tmp/0812/sprite.psd) in Photoshop and export it for me with the right color profile? I have the impression, when Gimp converts it to sRGB, it ends up looking too bright -- I found more info about it here on the web: http://www.usabilitypost.com/2008/07/30/photoshop-color-profiles-for-web-images/

So yeah, please save the file as sRGB IEC61966-2.1 for me, so the resulting sprite image doesn't end up looking like it's been washed too hot ;)

After that, I'll be able to make the new PNG file. I will probably check the file into the SVN tree in GIMP format, so it's easier for $contributor to use it in the future. Any objections?

Comment 7

[Michael Morgan [:morgamic]]

Reassigning to rdoherty, he has psd-friendly toolz.

Comment 8

[Fred Wenzel [:wenzel]]

Yeah no matter how we check it into the tree (as PSD or XCF) we should do so with the right color profile -- that's all I am asking ;)

Comment 9

[Ryan Doherty (:rdoherty)]

Attachment: Sprite as srgb png8

Here's the sprite exported as srgb and png8. 

NOTE: We will have to change the filename or append a url parameter to the image url to force users to download the new version. Our current expires headers set 10 years for images.

Comment 10

[Ryan Doherty (:rdoherty)]

Attachment: Fixed sprite

Latest sprite exported from psd with fixed tab color.

Comment 11

[Ryan Doherty (:rdoherty)]

Attachment: diff for new sprite url

Patch for new file url. I used the date at the end of the url instead of svn rev because there's no way to know the svn rev # until I commit. (And now way to insert it automatically with PHP)

Comment 12

[Fred Wenzel [:wenzel]]

Comment on attachment 352366 [details] [diff] [review]
diff for new sprite url

Looks good, but don't commit changes to style.css, please. I'll delete it in bug 464625.

Comment 13

[Ryan Doherty (:rdoherty)]

Attachment: New sprite url

New diff with no changes to style.css

Comment 14

[Fred Wenzel [:wenzel]]

Comment on attachment 352553 [details] [diff] [review]
New sprite url

wfm!

Comment 15

[Ryan Doherty (:rdoherty)]

r20741

Is there a set location in the tree for psds? We should check it in to svn.

Comment 16

[Fred Wenzel [:wenzel]]

(In reply to comment #15)
> Is there a set location in the tree for psds?

Don't think so -- but you could make one -- either as a subdirectory of webroot/img, or as a sibling to site/ and bin/, I suggest.

Comment 17

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Post-fix screenshot, blown up!

Comment 18

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #17)
> Created an attachment (id=352784) [details]
> Post-fix screenshot, blown up!

Microsoft Paint sucks, but this is still verified fixed :-)

Comment 19

[Stephen Donner [:stephend] Not actively reading bugmail]

Even though we svn-upped over in bug 471200, I still don't see this fixed on prod; reopening until we figure out why.

Comment 20

[Wil Clouser [:clouserw]]

Ryan:  We talked about this on IRC and I think we concluded it was due to a broken build script?  I remember you reproducing it but I've forgotten what the conclusion was.  Do you remember?

Comment 21

[Ryan Doherty (:rdoherty)]

(In reply to comment #20)
> Ryan:  We talked about this on IRC and I think we concluded it was due to a
> broken build script?  I remember you reproducing it but I've forgotten what the
> conclusion was.  Do you remember?

I wasn't able to reproduce the problem. I thought I had reproduced it, but I had edited a css file that wasn't included in the build script (another issue to fix). 

Right now I think pushing AMO again with a new revisions.php will fix the problem. That should update the query string.

Comment 22

[Fred Wenzel [:wenzel]]

FWIW, I tried reproducing it also but it worked as expected. Looks to me as revisions.php just didn't make it in when the build script run was committed?

Comment 23

[Michael Morgan [:morgamic]]

What's the status on this?

Comment 24

[Michael Morgan [:morgamic]]

Stephen - could you take a look at this and see if it is still an issue?

Comment 25

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #24)
> Stephen - could you take a look at this and see if it is still an issue?

It's always been an issue.  Comment 21 and 22 are talking about reproducing it in staging/dev environments; something in production (comment 22) just needs running.

Comment 26

[Stephen Donner [:stephend] Not actively reading bugmail]

Uh, so this now automagically fixed itself?  Anyone want to hazard a guess at what fixed this and when?

Comment 27

[Ryan Doherty (:rdoherty)]

(In reply to comment #26)
> Uh, so this now automagically fixed itself?  Anyone want to hazard a guess at
> what fixed this and when?

It's fixed on preview, so I think it's fixed. Still no definitive idea as to the cause.

Comment 28

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED in production.