398242 - Information bubble in download manager has no border

Status: RESOLVED FIXED

(SeaMonkey :: Themes, defect, P2)

Description

[[:Aleksej]]

Attachment: screenshot

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a9pre) Gecko/2007100104 Minefield/3.0a9pre
on Debian GNU/Linux lenny (testing).

Steps to reproduce:
1. Download a file
2. Tools→Downloads
3. Click the blue (i)

That makes it ugly&scary (“incomplete UI?!” “hang?”), and possibly less accessible.

Attachment 278230 [details] in bug 393701 shows it with a border in the Windows build 2007082500.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Dupe of bug 390711?

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

I'm guessing it is, yeah. 

Comment 3

[Daniel Holbert [:dholbert]]

Reopening / un-duping, as bug 390711 is now fixed, but this bug here is still broken.

(bug 390711 fixed autocomplete dropdowns, but not this bug's information bubble.)

Comment 4

[Sylvain Pasche]

By following the same path as in bug 390711, the "-moz-appearance: none" of the #information selector in themes/winstrip/mozapps/downloads/downloads.css could be ifdefed for GTK.
Or is there a better approach? (like adding a class to have separate -moz-appearance between gnomestripe and winstripe for some of the panels like autocomplete and this downloads information).

Comment 5

[Damon Sicore (:damons)]

+ing.  Making P2.

Comment 6

[Sylvain Pasche]

Attachment: ifdefing -moz-appearance

Same trick that was used for bug 390711

Comment 7

[Neil Deakin]

Comment on attachment 289061 [details] [diff] [review]
ifdefing -moz-appearance

Why is this a Linux only change?

Comment 8

[Sylvain Pasche]

(In reply to comment #7)
> (From update of attachment 289061 [details] [diff] [review])
> Why is this a Linux only change?

I thought the reason to have a -moz-appearance set to none was the same as bug 388317.
However I have just tested on Windows, and the visual appearance is the same if I drop the -moz-appearance property (like removing the ifdefs in my patch).

Moreover, I also get the same appearance for menus and autocomplete popups if I remove the changes in bug 388317. Did I miss something, or could something have changed which makes bug 388317 not valid any more?

Comment 9

[Neil Deakin]

Comment on attachment 289061 [details] [diff] [review]
ifdefing -moz-appearance

Is this patch still what is desired?

Comment 10

[Sylvain Pasche]

(In reply to comment #9)
> (From update of attachment 289061 [details] [diff] [review])
> Is this patch still what is desired?

Please have a look at bug 388317 comment 8.

Comment 11

[Sylvain Pasche]

Attachment: remove -moz-appearance

On winxp, the popup looks the same after dropping the -moz-appearance (see bug 388317 comment 10 for a possible explanation).

So this is just dropping the -moz-appearance for winstripe/gnomestripe.

Comment 12

[Reed Loden [:reed]]

(In reply to comment #11)
> So this is just dropping the -moz-appearance for winstripe/gnomestripe.

No, it's only removing it for winstripe. gnomestripe has a separate downloads.css now. You'll need to change it, too.

Comment 13

[Sylvain Pasche]

Comment on attachment 293238 [details] [diff] [review]
remove -moz-appearance

Thanks Reed. My objdir doesn't want to switch to gnomestripe for downloads.css, I'll try to clobber.

Comment 14

[Sylvain Pasche]

(In reply to comment #13)
> (From update of attachment 293238 [details] [diff] [review])
> Thanks Reed. My objdir doesn't want to switch to gnomestripe for downloads.css,
> I'll try to clobber.

hmm, that's bug 407044 comment 3 which is hitting me.

Comment 15

[Sylvain Pasche]

Attachment: patch

This one changes both winstripe and gnomestripe downloads.css

Comment 16

[Sylvain Pasche]

Looks like bug 405888 makes this obsolete