Closed
Bug 1003425
Opened 11 years ago
Closed 11 years ago
Opacity does not work with box-shadow, unless the background-color set
Categories
(Core :: Web Painting, defect, P3)
Tracking
()
People
(Reporter: nextdrift, Assigned: roc)
References
Details
(4 keywords)
Attachments
(2 files, 1 obsolete file)
|
766 bytes,
text/html
|
Details | |
|
9.61 KB,
patch
|
mattwoodrow
:
review+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140427195448
Steps to reproduce:
I'am create div element and add class 'test'
In .test create div element and add class 'shadow'
for .shadow ser css parametrs
position: absolute;
width: 100%;
height: 100%;
opacity: 0.5;
border-radius: 50%;
background: none;
box-shadow: 0 0 40px #000;
z-index: 1;
opacity dont work
if
background: rgba(0, 0, 0, 0);
opacity dont work
if
background: rgba(0, 0, 0, 0.01);
opacity working!
Actual results:
<!DOCTYPE html>
<html>
<head>
<title></title>
<style type="text/css">
.test {
position: absolute;
left: 100px;
top: 100px;
width: 50px;
height: 50px;
border-radius: 50%;
}
.test .shadow {
position: absolute;
width: 100%;
height: 100%;
opacity: 0.5;
border-radius: 50%;
background: rgba(0, 0, 0, 0);
/*background: none;*/
box-shadow: 0 0 40px #000;
z-index: 1;
}
.test .dot {
position: absolute;
width: 100%;
height: 100%;
border: 4px solid;
margin-top: -4px;
margin-left: -4px;
padding: 0;
border-radius: 50%;
background: green;
z-index: 2;
}
</style>
</head>
<body>
<div class="test">
<div class="shadow"></div>
<div class="dot"></div>
</div>
</body>
</html>
Expected results:
opacity on .test .shadow doesn't work, working only opacity = 0 or opacity = 1
|
Reporter | |
Updated•11 years ago
|
|
|
||
Comment 1•11 years ago
|
||
2014-05-06-03-02-04-mozilla-central-firefox-32.0a1.es-ES.linux-x86_64
Confirmed that opacity: 0.5 looks the same as opacity: 1.
|
|
||
Comment 2•11 years ago
|
||
Can you try making a more eye-friendly testcase, please? Maybe a bigger shadow, but I am not sure that's not affecting reproduction… Maybe that's the key, see the bug cited below.
Also, are you seeing it with Nightly, or with Firefox 29?
I am not sure I'm seeing the same bug, maybe there is a problem with Inspector… However, assuming it's bug 991046 for now.
In 2014-04-09-03-02-03-mozilla-central-firefox-31.0a1.en-US.linux-x86_64 5811efc11011,
the opacity doesn't change until I change it to 0 (and/or 1?). It may have worked in some earlier version.
In 2014-04-10-03-02-00-mozilla-central-firefox-31.0a1.ru.linux-x86_64 690c810c8e3e,
the opacity doesn't change until I change it to 0, and then anything but 0 looks like 1.
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5811efc11011&tochange=690c810c8e3e has bug 991046 about opacity.
Blocks: 991046
Status: UNCONFIRMED → NEW
QA Whiteboard: [bugday-20140512]
Component: Untriaged → Layout: View Rendering
Ever confirmed: true
Product: Firefox → Core
|
|
||
Comment 3•11 years ago
|
||
Matt, could you take a look?
tracking-firefox29:
--- → ?
tracking-firefox30:
--- → ?
tracking-firefox31:
--- → ?
tracking-firefox32:
--- → ?
Flags: needinfo?(matt.woodrow)
Keywords: regression
|
||
Comment 4•11 years ago
|
||
(In reply to [:Aleksej] from comment #2)
>
> In 2014-04-09-03-02-03-mozilla-central-firefox-31.0a1.en-US.linux-x86_64
> 5811efc11011,
> the opacity doesn't change until I change it to 0 (and/or 1?). It may have
> worked in some earlier version.
> In 2014-04-10-03-02-00-mozilla-central-firefox-31.0a1.ru.linux-x86_64
> 690c810c8e3e,
> the opacity doesn't change until I change it to 0, and then anything but 0
> looks like 1.
What is the difference between these two states? They both sound like the same thing to me.
I also can't reproduce this on OSX, might be a linux specific bug.
Flags: needinfo?(matt.woodrow)
|
|
||
Comment 5•11 years ago
|
||
The original report was done from firefox 29, seems unlikely that a firefox 31 change is responsible.
Keywords: regressionwindow-wanted
|
|
||
Comment 6•11 years ago
|
||
(In reply to Matt Woodrow (:mattwoodrow) from comment #4)
> (In reply to [:Aleksej] from comment #2)
> What is the difference between these two states? They both sound like the
> same thing to me.
In the first case, when the opacity starts changing, non-integer numbers give different opacities.
In the second case, only 0 is different from the rest.
|
||
Updated•11 years ago
|
status-firefox29:
--- → wontfix
status-firefox30:
--- → affected
status-firefox31:
--- → affected
status-firefox32:
--- → affected
|
||
Updated•11 years ago
|
Keywords: site-compat
|
|
||
Updated•11 years ago
|
tracking-firefox29:
+ → ---
|
||
Comment 8•11 years ago
|
||
Since this is possibly linux-only, we don't have to track this but can consider a low-risk uplift nomination when ready and depending on where we are in the cycle. We're close to shipping FF30 now and this is not a serious enough regression to block.
|
Assignee | |
Comment 9•11 years ago
|
||
I don't think this is Linux-only.
nsDisplayBoxShadowOuter::ApplyOpacity returns true and the nsDisplayOpacity is flattened away, so there's no layer for it. nsChangeHint_UpdateLayerOpacity is generated but only schedules a paint, since normally we're relying on layer construction/DLBI to detect that the layer tree (active or inactive) has changed and needs to be invalidated. But that doesn't happen in this case because there's no layer. So nothing invalidates the page.
|
|
Assignee | |
Comment 10•11 years ago
|
||
Assignee: nobody → roc
Attachment #8447112 -
Flags: review?(matt.woodrow)
|
|
||
Comment 11•11 years ago
|
||
Comment on attachment 8447112 [details] [diff] [review]
fix
Review of attachment 8447112 [details] [diff] [review]:
-----------------------------------------------------------------
Good catch.
Looks like nsDisplayBackgroundColor stores the opacity value as part of the retained geometry to handle this issue. I'd prefer to keep them consistent, not too fussed about which solution though.
|
|
||
Updated•11 years ago
|
Attachment #8447112 -
Flags: review?(matt.woodrow)
|
|
Assignee | |
Comment 12•11 years ago
|
||
Attachment #8447112 -
Attachment is obsolete: true
Attachment #8454277 -
Flags: review?(matt.woodrow)
|
|
||
Updated•11 years ago
|
Attachment #8454277 -
Flags: review?(matt.woodrow) → review+
|
|
Assignee | |
Comment 13•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
|
|
||
Updated•11 years ago
|
QA Whiteboard: [bugday-20140512] → [bugday-20140512] [good first verify]
Flags: qe-verify+
|
|
||
Comment 15•11 years ago
|
||
I managed to reproduce the initial bug on a Nightly from 2014-07-19.
This issue is now verified fixed on Linux(Xubuntu 14.04 64bit), using Firefox 34.0a1 (2014-08-26).
[bugday-20140827]
|
||
Comment 16•11 years ago
|
||
Thanks Oswaldo Ortiz!
I was able to reproduce this issue on Firefox 30 (20140605174243) using Windows 7 x64.
Verified fixed on Firefox 34 Beta 10 (20141117202603) using Windows 7 x64, Ubuntu 14.04 x32 and Mac OSX 10.9.5.
Status: RESOLVED → VERIFIED
status-firefox34:
--- → verified
|
||
Updated•10 years ago
|
Keywords: regressionwindow-wanted
|
||
Updated•7 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•