Closed Bug 1582819 Opened 4 months ago Closed 4 months ago

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

Categories

(Core :: Layout, task, P3)

task

Tracking

()

RESOLVED FIXED
mozilla71
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.

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.

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

Attachment #9094341 - Attachment description: Bug 1582819: Add diagnostic assert to catch elements with display:-moz-box or -moz-inline-box that were previously blockified to 'block' but won't be anymore. r?mats → 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
Pushed by dholbert@mozilla.com:
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
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
Regressions: 1584187
You need to log in before you can comment on or make changes to this bug.