1394575 - Box-shadow shown on XUL panel that has overflowed descendant even though panel has overflow:hidden (Linux only)

Status: NEW

(Core :: Layout, enhancement, P3)

Description

[Jared Wein [:jaws] (please needinfo? me)]

In bug 1387042 I added a large xul:image that is a child of a xul:box that has overflow:hidden. On Linux, the xul:panel shows a box-shadow where the image would have been visible if the xul:box did not have overflow:hidden. This box-shadow is only visible outside of the .panel-arrowcontent element.

This bug does not occur on Windows or OSX (possibly because on OSX we let the system do the panel shadow drawing).

To reproduce this bug, comment out the lines in /browser/themes/linux/customizableui/panelUI.css that set box-shadow to `none` for .panel-arrowcontent.

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #0)
> To reproduce this bug, comment out the lines in
> /browser/themes/linux/customizableui/panelUI.css that set box-shadow to
> `none` for .panel-arrowcontent.

And then after that, how do you reproduce the bug? (and how does the brokenness manifest?)  I just made the tweak you indicated here, and I didn't immediately see anything broken.  (using a linux mozilla-inbound build from today)

Based on bug 1387042's summary, I tried clicking the "..." page-action menu and choosing "Copy link", and I didn't encounter anything broken.

(Maybe we got lucky and this has become fixed? :D Probably not, though... In any case, doesn't sound like we need to bother worrying about this for 57, since we've got a workaround for it in panelUI.css. --> wontfix for that release)

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Screenshot from 2017-10-12 15-32-40.png

This bug still exists, I just confirmed it with the Nightly from October 11th.

Here's a screenshot, note that you should test on a page with a white background to make it easier to see. The screenshot shows this a little faded out but that's only because I couldn't get the timing of the screenshot program to catch this before it disappeared.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug

Thanks!  I can reproduce.  The unwanted artifact here is the extra-dark blocky shadow to the left of the "Copied!" button.

Here's a screencast which might make it a bit more obvious, too (using a local debug build from today, with the line of CSS commented out that jaws mentioned).

Comment 4

[Daniel Holbert [:dholbert]]

So I think the issue here isn't so much that we're violating the "overflow:hidden".  It's that the shadow is drawing differently (darker).  Even if we don't bother with "overflow", that drawing artifact happens, and it shouldn't.

Notably: I *don't* get the darker-colored shadows if I manually tweak "transform" rather than animating it.  So this has something to do with animations.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: diagnostic patch (make the issue more obvious)

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: screencast of this animation, with diagnostic patch applied

Here's a screencast of this animation, on Linux, with the diagnostic patch applied.

Note that:
 (1) when the image starts to overlap the box-shadow, the shadow seems to jump to full-opacity.
 (2) when the image moves off of the box-shadow, we leave artifacts behind from its top border.

Both of these seem problematic.  As noted above, neither problem seems to happen if I remove the transform animation, and instead make manual on-the-fly tweaks to the 'transform' property.

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: diagnostic patch v2 (make the issue more obvious)

(previous diagnostic patch wasn't quite complete -- in this version I'm removing the panel-autohide-after-1-second JS code, too, so that the slowed-down animation can complete.)