660682 - block child of inline element not rendered with parent's opacity

Status: RESOLVED FIXED

(Core :: Web Painting, defect)

Description

[nickers]

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]

Attachment: <div> inside <span> with opacity set

Comment 2

[Boris Zbarsky [:bzbarsky]]

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 [:bzbarsky]]

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)]

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)]

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)]

Attachment: fix

This works.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think this behavior is definitely justified on the principle of "least surprise".

Comment 8

[Boris Zbarsky [:bzbarsky]]

> 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 [:bzbarsky]]

Attachment: 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)]

(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 [:bzbarsky]]

> 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 [:bzbarsky]]

Comment on attachment 536217 [details] [diff] [review]
fix

r=me

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/b58ba54bdcbd

Comment 14

[Philipp von Weitershausen [:philikon]]

http://hg.mozilla.org/mozilla-central/rev/b58ba54bdcbd