1582819 - Add assertions to catch cases where we've been depending on implicit blockification of -moz-box

Status: RESOLVED FIXED

(Core :: Layout, task, P3)

Description

[Daniel Holbert [:dholbert]]

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.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: Bug 1582819: Add diagnostic assert to catch positioned elements with display:-moz-box or -moz-inline-box that were previously blockified to 'block' but won't be anymore. r?mats

Comment 2

[Daniel Holbert [:dholbert]]

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

[Tim Nguyen :ntim]

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

Comment 4

[Daniel Holbert [:dholbert]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=79400cbbd128da9f8830241060c1ad57ce77b584

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e79b84e42250
Add diagnostic assert to catch positioned elements with display:-moz-box or -moz-inline-box that were previously blockified to 'block' but won't be anymore. r=mats

Comment 6

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/e79b84e42250