I'd like to see if we can stop needing the XUL deck layout frame (which is applied to both deck and tabpanels elements): https://searchfox.org/mozilla-central/search?q=-moz-deck&path=xul.css.

• There are some accessibility tests but perhaps those could be converted to check tag name: https://searchfox.org/mozilla-central/search?q=nsDeckFrame&path=.
• We already have a selectedIndex setter: https://searchfox.org/mozilla-central/rev/1133b6716d9a8131c09754f3f29288484896b8b6/toolkit/content/widgets/general.js#11, which then gets read by the layout code: https://searchfox.org/mozilla-central/rev/227f5329f75bd8b16c6b146a7414598a420260cb/layout/xul/nsDeckFrame.cpp#84. We should be able to loop through children and set [collapsed=true] or some other attribute that will collapse the child in CSS, and then uncollapse the selected child.
• MozTabpanels (https://searchfox.org/mozilla-central/rev/1133b6716d9a8131c09754f3f29288484896b8b6/toolkit/content/widgets/tabbox.js#151) could then either inherit from customElements.get("deck") or implement the same logic itself.

Removing this would allow us to not need to add support for non-XUL-box children for nsDeckFrame in Bug 1558559.

Fyi: browser_globalwarnings.js was failing (https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=252707111&repo=try&lineNumber=11510) because XUL UI attempts to check visibility of an element from a hiding panel (#list-view), while it should check elements inside of #detail-view. It used to work because deck processed selectedIndex changes asynchronously in nsDeckFrame.cpp.

Here's a hack to allow you to experiment with using CSS Grid for this.
(this patch should be applied on top of the existing patch in this bug)

The magic spell to trigger the don't-blockify-my-children code is:

flex-direction: column;

(we can change it to something more appropriate later)

It seems to work reasonably well with Page Info, except that the default height (using a fresh profile) uses the max-content size of the children (it seems). Not sure how to avoid that...

(In reply to Mats Palmgren (:mats) from comment #4)

Created attachment 9089599 [details] [diff] [review]
grid-xul-hack

Here's a hack to allow you to experiment with using CSS Grid for this.
(this patch should be applied on top of the existing patch in this bug)

The magic spell to trigger the don't-blockify-my-children code is:

flex-direction: column;

(we can change it to something more appropriate later)

Thanks for the patch! I think once Bug 1580012 lands we can remove the hack from this patch and use just the CSS part.

It seems to work reasonably well with Page Info, except that the default height (using a fresh profile) uses the max-content size of the children (it seems). Not sure how to avoid that...

What's the difference between the current <deck> behavior and the max-content size? I thought <deck> used the tallest height from the children as well.

Sorry, I don't know how the XUL <deck> sizing works exactly.

This seems to fix the page-info issue for me (on Linux).

I think the way to push this patch forward is to figure out exactly what kind of sizing behaviour the <deck> usages need:

Children with all the same height/usage doesn't care about the height:

• places.xhtml (#placesViewDeck & #detailsDeck): removed in bug 1678523
• old about:addons: removed in bug 1674890
• old perf panel: should be removed in bug 1668219
• old about:config: removed in bug 1524836
• #modeDeck (dialog asking you to save or open directly): both children (menulist & button) have 30px height.
• .wizard-next-deck: both children are fixed-height buttons
• .wizard-page-box: removed in bug 1689830

Follows the biggest child's height (default deck behaviour):

• #updateDeck (both about dialog & preferences): removed in bug 1689727
• #setDefaultPane (preferences): removed in bug 1689742

Only takes the selected child height:

• #PanelUI-remotetabs-deck: https://searchfox.org/mozilla-central/rev/2efcda6dc74c63863fd8f04a6d9d7ac6b09c7eca/browser/themes/shared/customizableui/panelUI.inc.css#998
• #historyPane (preferences): https://searchfox.org/mozilla-central/rev/2efcda6dc74c63863fd8f04a6d9d7ac6b09c7eca/browser/themes/shared/preferences/preferences.inc.css#505-514
• #weavePrefsDeck (preferences): https://searchfox.org/mozilla-central/rev/2efcda6dc74c63863fd8f04a6d9d7ac6b09c7eca/browser/themes/shared/preferences/preferences.inc.css#505-514
• #fxaLoginStatus (preferences): https://searchfox.org/mozilla-central/rev/2efcda6dc74c63863fd8f04a6d9d7ac6b09c7eca/browser/themes/shared/preferences/preferences.inc.css#505-514
• #syncStatus (preferences): https://searchfox.org/mozilla-central/rev/2efcda6dc74c63863fd8f04a6d9d7ac6b09c7eca/browser/themes/shared/preferences/preferences.inc.css#505-514

Not sure:

• #translationEngine: not sure, but the MS translation logo (larger child I think) has only 38px height, so it depends on the parent notification padding
• #translationStates: not sure, but presumably? depends on whether the parent's default height (56px) is larger or not.
• #mainDeck (pageInfo window): a combination of largest child height and min-heights

Based on this, going with visibility: collapse seems reasonable.

So I'm going to go with visibility: collapse or display: none. The usages that need the <deck> height sizing behaviour will be converted to <stack> + visibility (bug 1689727, bug 1689742).

The rest should just work fine with visibility: collapse or display: none given they either already do it themselves with extra CSS (see comment 7) or don't care about the height.

XUL tabpanels will be split out to different bug.

Note to self: a11y code that might be affected https://searchfox.org/mozilla-central/rev/fd853f4aea89186efdb368e759a71b7a90c2b89c/accessible/generic/Accessible.cpp#331-337