Last Comment Bug 660682 - block child of inline element not rendered with parent's opacity
: block child of inline element not rendered with parent's opacity
Status: RESOLVED FIXED
spec issue
: testcase
Product: Core
Classification: Components
Component: Layout: View Rendering (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla7
Assigned To: Robert O'Callahan (:roc) (email my personal email if necessary)
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-30 11:55 PDT by nickers
Modified: 2011-06-20 22:32 PDT (History)
7 users (show)
roc: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
<div> inside <span> with opacity set (100 bytes, text/html)
2011-05-30 11:58 PDT, nickers
no flags Details
fix (2.10 KB, patch)
2011-05-30 20:42 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
bzbarsky: review+
Details | Diff | Splinter Review
Testcase showing such interleaving, albeit without stacking contexts (256 bytes, text/html)
2011-05-30 21:23 PDT, Boris Zbarsky [:bz] (still a bit busy)
no flags Details

Description nickers 2011-05-30 11:55:15 PDT
User-Agent:       Mozilla/5.0 (X11; Linux i686 on x86_64; rv:2.0.1) Gecko/20110430 Firefox/4.0.1 Iceweasel/4.0.1
Build Identifier: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0a1) Gecko/20110530 Firefox/7.0a1

If an inline element with opacity set has a block element child, rendering of the block element ignores parent's opacity.

Reproducible: Always

Steps to Reproduce:
View the attached testcase.

Actual Results:  
'Gamma' displayed black.

Expected Results:  
'Gamma' displayed gray.

http://www.w3.org/TR/2010/PR-css3-color-20101028/#transparency specifies that
descendant elements should be rendered with containing element's opacity:

    "Conceptually, after the element (including its descendants) is rendered into
    an RGBA offscreen image, the opacity setting specifies how to blend the
    offscreen rendering into the current composite rendering."
Comment 1 nickers 2011-05-30 11:58:06 PDT
Created attachment 536139 [details]
<div> inside <span> with opacity set
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2011-05-30 20:21:46 PDT
The CSS specs tend to be pretty schizophrenic about whether this sort of thing happens on elements or on boxes.  In particular they have a tendency to use "element" to mean both, but they're not exactly interchangeable.

In this case, the box for the block is NOT inside the box for the inline.  That means that rendering the inline does not actually render the block (per CSS2.1) which violates a basic assumption that the text quoted in comment 0 seems to be making about the drawing model.  In other words, that text can't possibly be correct, since it assumes things that are false about how painting happens in CSS.  The only question is what the text _should_ say instead.

roc, what do you think is the right behavior here?  Tantek, can you please fix the spec to actually make sense, no matter which behavior it's calling for?

Note that our current behavior matches WebKit and Presto.  Trident, in the form of IE9, applies the opacity setting to the block box as well.
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2011-05-30 20:34:17 PDT
Posted to www-style too: http://lists.w3.org/Archives/Public/www-style/2011May/0710.html
Comment 4 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-05-30 20:35:21 PDT
Does CSS actually define parent/child relationships between boxes yet?

We try reasonably hard to ensure that 'opacity' compositing is done on an entire element: elements with multiple boxes get those boxes fused together into a compositing group. My gut feeling is that this bug should be considered valid.
Comment 5 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-05-30 20:38:08 PDT
I think the only thing we need to do here is to add 'opacity:inherit' for anonymous block pseudos in ua.css.
Comment 6 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-05-30 20:42:45 PDT
Created attachment 536217 [details] [diff] [review]
fix

This works.
Comment 7 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-05-30 20:43:51 PDT
I think this behavior is definitely justified on the principle of "least surprise".
Comment 8 Boris Zbarsky [:bz] (still a bit busy) 2011-05-30 21:20:14 PDT
> Does CSS actually define parent/child relationships between boxes yet?

CSS 2.1 is working on it, half-heartedly.

> elements with multiple boxes get those boxes fused together into a compositing
> group.

Note that in the case of block-inside-inline you can have content interleaving between parent and its kids, as far as I can tell.  How does the attached patch (which seems like the obvious thing to me too, to get the simple cases working) deal with that.
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2011-05-30 21:23:27 PDT
Created attachment 536225 [details]
Testcase showing such interleaving, albeit without stacking contexts

If the argument is that the inline and its block kids should be a single stacking context, I can buy that (though the spec needs to say so, then; right now it doesn't really as far as I can tell), but the attached patch actually gives us either two or three stacking contexts in the {ib} case, right?  Is the difference not distinguishable through black-box testing?
Comment 10 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-05-30 22:04:06 PDT
(In reply to comment #9)
> If the argument is that the inline and its block kids should be a single
> stacking context, I can buy that (though the spec needs to say so, then;
> right now it doesn't really as far as I can tell),

That's right.

> but the attached patch
> actually gives us either two or three stacking contexts in the {ib} case,
> right?  Is the difference not distinguishable through black-box testing?

Here's what our implementation would do in your testcase if the span had opacity:
-- The two inline frames and the anonymous block each generate an nsDisplayOpacity containing their child frame content
-- The nsDisplayOpacitys are placed on the PositionedDescendants list as Appendix E requires
-- We notice that the three nsDisplayOpacitys are all for the same element, and are consecutive in z-order, so we fuse them into a single group and get the right rendering.

We might get into a situation where we fail to fuse nsDisplayOpacitys for the same element because other content is interleaved with it in z-order, even after we've moved the display items to the list corresponding to Appendix E 2.8. However, I think such a situation would mean a bug in the specs or our implementation for allowing such a thing to happen.
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2011-05-31 06:00:24 PDT
> We might get into a situation where we fail to fuse nsDisplayOpacitys for the
> same element because other content is interleaved with it in z-order

That's the case I'm worried about, yes.

> However, I think such a situation would mean a bug in the specs or our
> implementation for allowing such a thing to happen.

Ok, as long as you can't think of ways it can happen right now things are good.
Comment 12 Boris Zbarsky [:bz] (still a bit busy) 2011-05-31 06:00:55 PDT
Comment on attachment 536217 [details] [diff] [review]
fix

r=me
Comment 13 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-06-16 20:54:35 PDT
http://hg.mozilla.org/integration/mozilla-inbound/rev/b58ba54bdcbd
Comment 14 Philipp von Weitershausen [:philikon] 2011-06-17 07:37:06 PDT
http://hg.mozilla.org/mozilla-central/rev/b58ba54bdcbd

Note You need to log in before you can comment on or make changes to this bug.