"ASSERTION: Should have a block here!" with ruby-base-container, canvas with display: table-cell

NEW
Assigned to

Status

()

Core
Layout
3 years ago
3 years ago

People

(Reporter: Jesse Ruderman, Assigned: xidorn)

Tracking

(Blocks: 2 bugs, {assertion, testcase})

Trunk
assertion, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox40 affected)

Details

Attachments

(3 attachments)

(Reporter)

Description

3 years ago
Created attachment 8591579 [details]
testcase

###!!! ASSERTION: Should have a block here!: '!next || !frame->IsInlineOutside()', file layout/base/nsCSSFrameConstructor.cpp, line 498
(Reporter)

Comment 1

3 years ago
Created attachment 8591580 [details]
stack
(Assignee)

Updated

3 years ago
OS: Mac OS X → All
Hardware: x86_64 → All
(Assignee)

Comment 2

3 years ago
Created attachment 8592071 [details] [diff] [review]
patch

The assertion is violated because:
1. we do not create pseudo table structure to wrap the canvas with table-cell display type, then
2. the canvas becomes an inline descendant inside ruby base, then
3. since table-cell is not inline outside, we create {ib} split for it, but
4. the display type of the created {ib} split block is inlinized by style fixup.

This patch forces any unknown non-inline-outside display type to become inline-block in EnsureInlineDisplay to solve this problem.
Assignee: nobody → quanxunzhen
Attachment #8592071 - Flags: review?(dbaron)
Comment on attachment 8592071 [details] [diff] [review]
patch

Presumably this happens as a result of frames that are constructed by tag instead of by display property?  If so, the NS_WARNING seems inappropriate; we shouldn't emit warnings for valid markup.  But maybe instead add a comment explaining how we get in this situation.

r=dbaron with that
Attachment #8592071 - Flags: review?(dbaron) → review+
(Assignee)

Comment 4

3 years ago
I just found that this change breaks cases like

<ruby>
  <div style="display: table-cell">

which we test in ruby-inlinize-blocks-003.

Though I don't think it is something important we need to care, I want to confirm that may I remove that test with this change?
Flags: needinfo?(dbaron)
(Assignee)

Comment 5

3 years ago
(In reply to David Baron [:dbaron] ⏰UTC-7 from comment #3)
> Comment on attachment 8592071 [details] [diff] [review]
> patch
> 
> Presumably this happens as a result of frames that are constructed by tag
> instead of by display property?

I thought so, but it seems that it also happens when we construct frames merely by display property, because anonymous box constructing happens after computation of those styles.
(Assignee)

Comment 6

3 years ago
Ahh... It doesn't match what the spec says currently:

Inlinize block-level boxes: ... This computation occurs after any intermediary anonymous-box fixup (such as that required by internal table elements.

But it is impossible to ensure everything gets inlinized after the fixup. I'll bring it up on www-style.
Sounds like you're emailing www-style, so the question is no longer relevant.
Flags: needinfo?(dbaron)
You need to log in before you can comment on or make changes to this bug.