659465 - fix clipping and border radius of global warnings in add-ons manager

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, defect)

Description

[Frank Yan (:fryn)]

The #view-port-container tries to clip its content using border-radius: 5px, but that doesn't totally work, because its .global-*-warning descendants use background-images and -colors.

Also, when there are multiple global-*-warnings, the non-first warnings should not have non-zero border radii.

Comment 1

[Frank Yan (:fryn)]

Attachment: patch :)

Comment 2

[Frank Yan (:fryn)]

Attachment: screenshot of bug

Comment 3

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 534909 [details] [diff] [review]
patch :)

Well that makes a rather nice difference :)

It breaks the corners of the plugin check link in the plugins pane, however. Will attach a screenshot.

Comment 4

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Attachment: Screenshot of PluginCheck link

Comment 5

[Frank Yan (:fryn)]

(In reply to comment #4)
> Created attachment 534994 [details]
> Screenshot of PluginCheck link

Ah, I guess there's actually a hidden node in that case :\
Hmm, I think I have a solution. Will update patch with it if it works.

Comment 6

[Frank Yan (:fryn)]

I looked at https://mxr.mozilla.org/mozilla-central/source/toolkit/themes/winstripe/mozapps/extensions/extensions.css#93 , and there doesn't seem to be a solution for this, besides what we did for bug 595656 :(

Is bug 623615 still blocking the fix of that?

Comment 7

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #6)
> Is bug 623615 still blocking the fix of that?

Sadly, yes - and probably will be for some time.

Adding a border radius to the .global-info-container node (the parent of the PluginCheck link) didn't fix the corners there?

Comment 8

[Frank Yan (:fryn)]

(In reply to comment #7)
> Adding a border radius to the .global-info-container node (the parent of the
> PluginCheck link) didn't fix the corners there?

It fixes the corners in that case, but we want the border-radius to apply only to the first non-hidden global-*-container and since we don't hide them using hidden="true", we can't do it robustly via CSS without enumerating every single case, which would result in a very long chain of selectors and would break whenever a change is made to any other style that affects when the global-*-containers are shown.

If we hid them using hidden="true", we could do sth like:
.view-header { border-radius: 4px; }
.view-header:not([hidden=true]) ~ .view-header { border-radius: 0; }

Comment 9

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Oh, in that case the selector can just check the "warning" attribute on the root (<page>) element.

Note that in the plugins pane, we don't show the safemode warning (warning="safemode"). So if there's a warning shown on that pane, the warning attribute will have the value of either "updatesecurity" or "checkcompatibility".

(I'd much rather see this approach land and actually fix something, than wait hopefully for bug 623615.)

Comment 10

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Yoink!

Comment 11

[Frank Yan (:fryn)]

(In reply to comment #9)
> Oh, in that case the selector can just check the "warning" attribute on the
> root (<page>) element.

> (I'd much rather see this approach land and actually fix something, than
> wait hopefully for bug 623615.)

I wrote "Okay! I'll give it another shot." and assigned it to myself, but then I mid-air collided with you yoinking it. :P

Comment 12

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Epic timing is epic.

I noticed that the parent of the plugincheck link from bug 656269 has an unconditional border-radius (which is why I yoinked it) - wanna fix that up too?

Comment 13

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #12)
> I noticed that the parent of the plugincheck link from bug 656269 has an
> unconditional border-radius

Oh, and gnomestripe doesn't have it at all.

Something is a bit funky there...

Comment 14

[Frank Yan (:fryn)]

(In reply to comment #13)
> (In reply to comment #12)
> > I noticed that the parent of the plugincheck link from bug 656269 has an
> > unconditional border-radius

Yes, that's part of what I was trying to show in https://bug659465.bugzilla.mozilla.org/attachment.cgi?id=534910

> Oh, and gnomestripe doesn't have it at all.

I noticed that too. Not sure if it's a bug or just weird override usage as per https://mxr.mozilla.org/mozilla-central/source/toolkit/themes/Makefile.in#49
I'll test on Ubuntu tomorrow.

Comment 16

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Frank: Do you still intend on finishing this?

Comment 17

[Frank Yan (:fryn)]

Yes, but it's low on my list, and I'm also on PTO right now and into next week. Feel free to take it. Unassigning myself for now to avoid ambiguity.

Comment 19

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Bug 623615 has been fixed (via bug 716439), so this can be fixed the easy way by re-enabling the fix from bug 595656 (ie, use overflow:hidden).