-moz-box-shadow does not work properly on <embed>

VERIFIED FIXED in mozilla1.9.2a1

Status

()

P3
normal
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: eisa01, Assigned: ventnor.bugzilla)

Tracking

({testcase})

Trunk
mozilla1.9.2a1
testcase
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.1 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; nb-no) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090128 Minefield/3.2a1pre

For an empty <object> with defined height and width, no shadow is applied.
For an <object> with contents, the shadow is displayed wrong (too low).

Reproducible: Always




See test case
I also discovered that if I set the background to e.g. red, it is not displayed for the empty <object>, but for the <object> with contents it is filled, but you're not supposed to see it because the flash animation should block it.
(Reporter)

Comment 1

10 years ago
Created attachment 359283 [details]
Test case
(Reporter)

Comment 2

10 years ago
Created attachment 359284 [details]
Expected result

Left is Mozilla, right is Safari. I expect the result to be similar.
(Reporter)

Updated

10 years ago
Blocks: 212633
Flags: wanted1.9.1?
Version: unspecified → Trunk
Confirmed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
Assignee: nobody → ventnor.bugzilla
(Assignee)

Comment 4

10 years ago
This is not a box-shadow bug. This is because of a difference between webkit and gecko. Webkit seems to treat objects as block frames, so it is able to accept an explicit size and use that. Gecko treats objects as inline frames so it can't accept explicit sizes, you'll see that backgrounds and borders give the same symptoms.

Setting the object frames to display: block fixes the issue.
(In reply to comment #0)
> For an empty <object> with defined height and width, no shadow is applied.

That's because an empty <object> simply triggers fallback to the <object>'s inline content. The <object> itself is treated like a span --- an inline element --- which does not support width/height sizing. Our rendering is correct in this case, or at least, it's not violating any spec.

> For an <object> with contents, the shadow is displayed wrong (too low).

That's because we're rendering the <embed>, which has no shadow. The object element again is treated just as an inline element, and again the width and height are ignored.

Now, if you put the box-shadow rule on the embed, then it should work. But it doesn't --- and that's a real bug.
Summary: -moz-box-shadow does not work properly on <object> → -moz-box-shadow does not work properly on <embed>
(Assignee)

Comment 6

10 years ago
Created attachment 359453 [details] [diff] [review]
Patch

Turns out we needed to include overflow in the frame's bounds so the box shadow isn't "optimized" away.
Attachment #359453 - Flags: superreview?(roc)
Attachment #359453 - Flags: review?(roc)
Attachment #359453 - Flags: superreview?(roc)
Attachment #359453 - Flags: superreview+
Attachment #359453 - Flags: review?(roc)
Attachment #359453 - Flags: review+
Keywords: checkin-needed
Whiteboard: [needs landing]
We should have a reftest here, but I guess it depends on the test plugin working on all platforms.
Flags: in-testsuite?
http://hg.mozilla.org/mozilla-central/rev/2676947cb41c
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing] → [needs 191 landing]
Comment on attachment 359453 [details] [diff] [review]
Patch

Straightforward fix for a bug in a new feature
Attachment #359453 - Flags: approval1.9.1+
(In reply to comment #7)
> We should have a reftest here, but I guess it depends on the test plugin
> working on all platforms.

You can make it platform-specific at the moment:
http://mxr.mozilla.org/mozilla-central/source/modules/plugin/test/reftest/reftest.list

We'll get the windows/gtk drawing code landed soon, anyway. Might as well write the test!
Sorry, but that doesn't work on trunk with the checked-in patch. I did a test with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090201 Minefield/3.2a1pre and the behavior is still the same. Identically results I get on Windows.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 12

10 years ago
Comment on attachment 359283 [details]
Test case

Test case turned out to be incorrect
Attachment #359283 - Attachment is obsolete: true
(Reporter)

Comment 13

10 years ago
Created attachment 360021 [details]
Test case #2

Now applies the style to the <embed> element
(Reporter)

Comment 14

10 years ago
(In reply to comment #11)
> Sorry, but that doesn't work on trunk with the checked-in patch. I did a test
> with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre)
> Gecko/20090201 Minefield/3.2a1pre and the behavior is still the same.
> Identically results I get on Windows.

It works just fine for me on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090201 Minefield/3.2a1pre

The test case was incorrect as it applied the style to the <object> element

btw, I also want to say thanks for fixing this and bug 475197 so fast, I'm impressed :)
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → FIXED
Thanks for the hint. I checked again with the above build and everything is fine. Marking as verified.
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla1.9.2a1
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/e98e69040f91
Keywords: checkin-needed → fixed1.9.1
Whiteboard: [needs 191 landing]
Verified with:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090204 Shiretoko/3.1b3pre Ubiquity/0.1.5 ID:20090204020327

For now no verification on Windows is possible because the gfx drawing code hasn't been landed yet. See comment 10. Ted, do you have a bug number we can add to the dependency list?
Keywords: fixed1.9.1 → verified1.9.1
The Windows test plugin drawing code landed in bug 469830. The gtk2 plugin drawing code is bug 469831.
Depends on: 469830, 469831
Flags: wanted1.9.1? → wanted1.9.1+
Priority: -- → P3
I think we should back this out (and bug 478267) on branch to fix bug 479637 on branch. The work required to fix bug 479637 properly in a branch-safe way isn't justified by this fix.

On trunk, my work on plugin hoisting will fix bug 479637.
Depends on: 479637
Whiteboard: [needs landing]
Whiteboard: [needs landing] → [needs 191 landing]
Backed out of 1.9.1: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/91b65591babb

So this is no longer fixed in 1.9.1, and we don't plan to fix it there.
Keywords: verified1.9.1
Whiteboard: [needs 191 landing]

Updated

10 years ago
Attachment #359453 - Flags: approval1.9.1+

Comment 22

10 years ago
(In reply to comment #18)
> The Windows test plugin drawing code landed in bug 469830. The gtk2 plugin
> drawing code is bug 469831.

So, Aaron (cc'd) is looking at writing a test for this bug. However, if you use the test plugin, the box shadow is drawn in both Minefield and Shiretoko.  If you use the original flash based testcase, the box shadow is only drawn on Minefield.  We need some direction here about what's really going on in order to test this.  

I don't think we can countenance checking in Flash into reftests :)
(Assignee)

Comment 23

10 years ago
(In reply to comment #22)
> So, Aaron (cc'd) is looking at writing a test for this bug. However, if you use
> the test plugin, the box shadow is drawn in both Minefield and Shiretoko.  If
> you use the original flash based testcase, the box shadow is only drawn on
> Minefield.  We need some direction here about what's really going on in order
> to test this.  
> 
> I don't think we can countenance checking in Flash into reftests :)

I presume because the test plugin is windowless by default. Windowless plugins work fine, but plugins in windowed mode show this bug.
The test plugin supports wmode="window".
(Assignee)

Comment 25

10 years ago
And Linux doesn't support getting the contents of Windowed plugins in a consistent manner due to an unfortunate optimization of X.

Comment 26

10 years ago
Created attachment 376755 [details]
A simple test that uses the test plugin

(In reply to comment #24)
> The test plugin supports wmode="window".
I've attached a simple test that uses this attribute on the embed tag and still displays the drop shadow in both minefield and shiretoko.

Minefield: (an old debug build) Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090423 Minefield/3.6a1pre

Shiretoko: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090508 Shiretoko/3.5b5pre
Michael,

With the above test case running on 

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b5pre) Gecko/20090511 Shiretoko/3.5b5pre

I get no visual whatsoever (blank white screen).

Is this a result in reference to your comments above in regards to Linux?
(In reply to comment #26)
> > The test plugin supports wmode="window".
> I've attached a simple test that uses this attribute on the embed tag and still
> displays the drop shadow in both minefield and shiretoko.
> 
> Minefield: (an old debug build) Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5;
> en-US; rv:1.9.2a1pre) Gecko/20090423 Minefield/3.6a1pre
> 
> Shiretoko: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
> rv:1.9.1b5pre) Gecko/20090508 Shiretoko/3.5b5pre

Mac never uses the windowed plugin path. Only Windows and Linux do.
(In reply to comment #27)
> Michael,
> 
> With the above test case running on 
> 
> Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b5pre) Gecko/20090511
> Shiretoko/3.5b5pre
> 
> I get no visual whatsoever (blank white screen).
> 
> Is this a result in reference to your comments above in regards to Linux?

Aaron: you'd need a self-compiled build of Firefox in order to have the test plugin available.

roc: I see a drop-shadow in Clint's test with a fairly recent Windows trunk build.
Yeah, because this is fixed on trunk. On 1.9.1 you should see the bug.
(Assignee)

Comment 31

10 years ago
(In reply to comment #27)
> Michael,
> 
> With the above test case running on 
> 
> Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b5pre) Gecko/20090511
> Shiretoko/3.5b5pre
> 
> I get no visual whatsoever (blank white screen).
> 
> Is this a result in reference to your comments above in regards to Linux?

No, my comment was about if you were going to make a reftest about this; on Linux we don't support compositing of windowed plugins onto <canvas> and the like. Your issue is due to this bug. It doesn't happen on Mac because Mac doesn't support windowed plugins.
You need to log in before you can comment on or make changes to this bug.