Assertion failure: !(f->GetStateBits() & NS_FRAME_PART_OF_IBSPLIT) (anonymous ib-split block shouldn't have border/background)
Categories
(Core :: Web Painting, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr52 | --- | wontfix |
| firefox-esr60 | --- | wontfix |
| firefox-esr68 | --- | wontfix |
| firefox55 | --- | wontfix |
| firefox56 | --- | wontfix |
| firefox57 | --- | wontfix |
| firefox58 | --- | wontfix |
| firefox59 | --- | wontfix |
| firefox61 | --- | wontfix |
| firefox62 | --- | wontfix |
| firefox63 | --- | wontfix |
| firefox70 | --- | wontfix |
| firefox71 | --- | wontfix |
| firefox72 | --- | fixed |
People
(Reporter: jkratzer, Assigned: MatsPalmgren_bugz)
References
(Blocks 1 open bug)
Details
(Keywords: assertion, crash, testcase, Whiteboard: [fuzzblocker], [wptsync upstream])
Attachments
(4 files, 3 obsolete files)
|
||
Comment 1•7 years ago
|
||
|
|
||
Updated•7 years ago
|
|
||
Updated•7 years ago
|
|
||
Comment 2•7 years ago
|
||
|
||
Comment 3•7 years ago
|
||
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
|
||
Comment 4•5 years ago
|
||
Maire, Jessie, could you please help finding someone to fix the fuzz blocker?
It means that it is preventing us to fuzz some big part of the code because we hit this issue pretty quickly.
|
||
Comment 5•5 years ago
|
||
Mats, could you take a look at this? Thanks
|
|
||
Comment 6•5 years ago
•
|
||
A Pernosco session is available here: https://pernos.co/debug/rNt4Jwec6Q7lJUYh85_59w/index.html
It will expire in 7 days.
|
||
Comment 7•5 years ago
|
||
Looking at the pernosco link, I think the assertion is just invalid. We have mask inherited into the ib-split anonymous block, and the mask code does compute the box decoration rect. The ib-split sibling still doesn't have borders or backgrounds of course.
|
|
||
Comment 8•5 years ago
|
||
Oh, though I guess if it can be reached for those, the idea is that it should use the GetNextContinuationOrIBSplit* stuff?
|
|
||
Comment 9•5 years ago
|
||
While IB-split block wrappers cannot indeed have borders or backgrounds, we
inherit mask from the inline into them1, and the masking code can reach this
code too.
I think just using the block continuations rather than walking inlines is the
right thing to do here.
|
Assignee | |
Comment 10•5 years ago
|
||
Right, I came to the same conclusion and I'm working on adding some WPTs for the actual layout too, so I should probably take this. https://treeherder.mozilla.org/#/jobs?repo=try&revision=911fe70c1dc415577a544a48d2bf12e3eb86dcad
That said, I'm not really sure there is a spec that defines this clearly...
|
|
Assignee | |
Comment 11•5 years ago
•
|
||
The spec doesn't really address the ib-split case AFAICT: https://drafts.csswg.org/css-break-3/#joining-boxes
I'm guessing the assumption is that block-in-inline splitting is done per CSS2: https://www.w3.org/TR/CSS2/visuren.html#img-anon-block which seems to suggest the embedded block shouldn't be included in the continuation chain at all, i.e. something like this:
<p><span>...<div></div>...</span></p>
becomes:
<p>
<p:anon-block>
<span frag1>...</>
</p:anon-block>
<div></div>
<p:anon-block>
<span frag2>...</>
</p:anon-block>
</p>
(I think that would violate our box tree invariants though. We'd need to link the two <p:anon-block>s as continuations.)
|
|
||
Comment 12•5 years ago
|
||
Yeah, that is probably a no-go. Having such a frame structure would also mean that there'd be no proper way to do opacity on the <span> apply to the <div>, which is required per spec (but Chrome/WebKit don't do it, IIRC).
|
|
||
Comment 13•5 years ago
|
||
(In reply to Mats Palmgren (:mats) from comment #10)
Right, I came to the same conclusion and I'm working on adding some WPTs for the actual layout too, so I should probably take this.
Thanks!
|
||
Updated•5 years ago
|
|
|
Assignee | |
Comment 14•5 years ago
|
||
Yeah, the box tree that CSS2 suggests is impractical. I think we want the <div> boxes as children of some <span> box, which is what we have.
no proper way to do opacity on the <span> apply to the <div>, which is required per spec
Do you have a spec/issue link? That strongly suggests that mask-image, filters etc should also be applied on the <div>.
|
|
||
Comment 15•5 years ago
|
||
See all the discussion in bug 660682, but basically https://drafts.csswg.org/css-color/#transparency mentions element + descendants, not boxes.
We apply opacity also to stuff like fixed pos and such:
<!doctype html>
<div style="opacity: 0.5">
<div style="position: fixed; height: 100px; width: 100px; background: green"></div>
</div>
|
|
Assignee | |
Comment 16•5 years ago
|
||
Yeah, it seems Chrome has no problem applying these on fixed pos child boxes.
|
|
Assignee | |
Comment 17•5 years ago
|
||
Chrome is at least consistent in NOT applying them to block-in-inline child boxes.
(Whereas Gecko do apply these consistently.)
|
|
Assignee | |
Comment 18•5 years ago
•
|
||
The spec language at:
https://drafts.fxtf.org/css-masking-1/#the-mask-image
A computed value of other than none results in the creation of a stacking context [CSS21] the same way that CSS opacity [CSS3COLOR] does for values other than 1.
seems clear that all these properties should be handled the same as opacity, so they should be applied also for the block-in-inline case.
Which leaves my original question unanswered: how are these fragments supposed to be joined together?
I think our current layout is reasonable. Basically, treat the inline fragments as if the blocks don't exist, and the blocks (each block element separately though) as if the inlines don't exist. I'll file a spec issue though, because the spec needs to define this more precisely...
|
|
Assignee | |
Comment 19•5 years ago
|
||
|
||
Updated•5 years ago
|
|
|
Assignee | |
Comment 20•5 years ago
|
||
|
|
Assignee | |
Comment 21•5 years ago
|
||
|
||
Comment 22•5 years ago
|
||
|
||
Comment 25•5 years ago
|
||
| bugherder | ||
|
|
||
Updated•5 years ago
|
Description
•