Add assertions to catch cases where we've been depending on implicit blockification of -moz-box
Categories
(Core :: Layout, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox71 | --- | fixed |
People
(Reporter: dholbert, Assigned: dholbert)
References
Details
Attachments
(1 file)
In bug 1580012 (and bug 1582530), we're exploring letting -moz-box
blockify to itself (rather than to block
), in the interests of transparently removing XUL grid/deck/stack and replacing them with CSS Grid (whose items may still want to be -moz-box
).
Right now we have some XUL elements that happen to be blockified to block
via being position:absolute
or fixed
, or being flex items, and those items may depend on having display:block
and become broken when we relax the blockfication.
I'm filing this bug on adding some assertions to help catch those items. The goal of these assertions are to throw up an alarm for any element that is both display:-moz-box
and also out-of-flow or a flex item (because up until now, that situation has not been possible, because the display
would have been implicitly converted to block
). ntim is going through and adding explicit display:block to these elements in bug 1582316 (to restore the computed styles that they've already been ending up with), so the goal of these assertions will be to help find elements that need this treatment.
Assignee | ||
Comment 1•5 years ago
|
||
Assignee | ||
Comment 2•5 years ago
|
||
ntim: you probably want to poke around with this patch applied, to find more bits of UI that will want to add display:block
to preserve behavior.
I started up Firefox with this patch and went to the "customize Firefox" UI, and I hit the first issue there, for this XULLabel, which seems to be the caption inside of the (initially-empty) Overflow Menu:
FlexContainer(box)(13)@7f0d86a877d8 parent=7f0d8c8671a0 next=7f0d8bf9ff78 {0,0,0,0} [state=0002060000140603] [content=7f0d8cdf5dc0] [cs=7f0d8ba124d8]<
FlexContainer(box)(1)@7f0d86a87880 parent=7f0d86a877d8 next=7f0d88f57110 {0,0,0,0} [state=0000060000100603] [content=7f0d8812f310] [cs=7f0d8bcba028]<
FlexContainer(box)(0)@7f0d86a87928 parent=7f0d86a87880 next=7f0d86a87be0 {0,0,0,0} [state=0000060000100603] [content=7f0d8812f3a0] [cs=7f0d8c5215c8]<
XULLabel(label)(0)@7f0d880fcd90 parent=7f0d86a87928 next=7f0d86a87ac0 {0,0,0,0} [state=0000060000d00402] [content=7f0d8812f430] [cs=7f0d8c043b58]<
line 7f0d86a87a70: count=1 state=inline,dirty,prevmarginclean,not-impacted,not-wrapped,before:nobr,after:nobr[0x1] {0,0,0,0} <
Text(0)"Drag your favorite items into the toolbar or overf"@7f0d86a879d0 parent=7f0d880fcd90 {0,0,0,0} [state=0000000020000402] [content=7f0d8806bc00] [cs=7f0d84b403d8:-moz-text] [run=7f0d8315f660][0,59,T]
>
>
That XULLabel is a flex item in a CSS Flex container, which was previously getting automatically promoted to display:block
but will not anymore.
Comment 3•5 years ago
|
||
Thanks for letting me know! AFAIK, many flex children that used to be blockified now look just fine not blockified, so it may not look broken. Though the assertion will be useful to test out these cases though, thanks :)
Updated•5 years ago
|
Assignee | ||
Comment 4•5 years ago
|
||
Comment 6•5 years ago
|
||
bugherder |
Description
•