Status

()

For bugs in Firefox Desktop, the Mozilla Foundation's web browser. For Firefox user interface issues in menus, bookmarks, location bar, and preferences. Many Firefox bugs will either be filed here or in the Core product. Bugs for developer tools (F12) should be filed in the DevTools product. (more info)

Ouch, this is pretty bad. :-\
Just in case people try this: If you get in this state and need to get out, you can still hit [esc] on your keyboard or switch to a different tab - but it might be better to just remove things from the overflow menu again. :-|

Dan, could you help me out with something here? I'm trying to use flex box to have the 'panel' item in customize mode (the bit encased in blue graph paper style background on the right) that basically only takes up the space it needs, but equally doesn't end up making the window bigger / putting the footer off-screen.
I'm struggling quite a bit - some of the flexbox stuff doesn't seem to want to do what it should in XUL. This WIP patch has 2 issues:
- the panel grows beyond the size of the items it contains. This is a consequence of the height: 0 and flex-grow: 1, AIUI, but without the height: 0 it never gets smaller if the window gets smaller, and without the flex-grow it always stays minimum height (but with padding, which is a bit odd).
- when this happens, the items end up at the bottom. I tried using align-items or justify-content to fix this, but that didn't seem to help. The only thing that seems to help is the position:relative styling that gets applied on hover (for unrelated reasons, we can probably get rid of it with photon, it had to do with how we position items in the old grid-style menu), but that feels like a weird hack.
Any idea what I should be doing differently?
artifact trypush with patch (should have builds in the next half hour or so):
https://treeherder.mozilla.org/#/jobs?repo=try&revision=991df33fa25edd30e1523e339e9b07806b8b90f3

(In reply to :Gijs from comment #2)
> This is a
> consequence of the height: 0 and flex-grow: 1, AIUI, but without the height:
> 0 it never gets smaller if the window gets smaller, and without the
> flex-grow it always stays minimum height (but with padding, which is a bit
> odd).
Does it help if you use "min-height:0" instead of "height:0"? That should address the never-gets-smaller-if-the-window-gets-smaller issue just as well, I think.

Oh, sorry -- disregard comment 4. I'm now seeing that the element in question (in your WIP patch) has "overflow-y:auto" which should already be making us treat min-height:auto as min-height:0... so clearly that's not the solution.

(In reply to :Gijs from comment #2)
> - when this happens, the items end up at the bottom. I tried using
> align-items or justify-content to fix this, but that didn't seem to help.
Devtools show that this is because of a "::before" pseudo-element with "height:100%". This absorbs all of the free space and pushes the other items to the end. Specifically, it's from this CSS:
=========
#main-window[customize-entered] .customization-target:not(:-moz-any(#PanelUI-contents, #TabsToolbar, #toolbar-menubar))::before {
/* Prevent jumping of tabs when switching a window between inactive and active (bug 853415). */
-moz-box-ordinal-group: 0;
content: "";
display: -moz-box;
height: 100%;
left: 0;
outline-offset: -2px;
pointer-events: none;
position: absolute;
top: 0;
width: 100%;
}
=========
If I change that pseudo-element to "display:none", then the other children all snap to the start (and successfully position themselves with "justify-content" etc.)
If you can get rid of that pseudo-element, things might behave more predictably. (Having said that, I don't see why we're setting aside space for that pseudo-element -- it's "position:absolute" so it shouldn't steal any space away from real flex items, ever since bug 874718.)

Comment on attachment 8880613[details][diff][review]
WIP patch
Review of attachment 8880613[details][diff][review]:
-----------------------------------------------------------------
(In reply to Daniel Holbert [:dholbert] from comment #7)
> Created attachment 8880937[details][diff][review]
> WIP v2
>
> Gijs, here's a modified version of your patch which seems to do what you
> want (I think) -- can you give this a try?
Yes! This is great. Thanks so much. I will have to make some more changes to make the panel arrow stuff work, but this is great. Thanks for the update and the helpful comments!
Which of these changes ends up getting rid of the issue in comment #6 ? Or is it just that the vbox#widget-overflow-fixed-list itself now doesn't grow anymore, and so it stops happening? Is it worth filing a bug on the issue identified there (ie abspos element shouldn't influence the rest of the layout) ?

(In reply to :Gijs from comment #9)
> Which of these changes ends up getting rid of the issue in comment #6 ? Or
> is it just that the vbox#widget-overflow-fixed-list itself now doesn't grow
> anymore, and so it stops happening?
I think that's exactly it, yeah.
> Is it worth filing a bug on the issue
> identified there (ie abspos element shouldn't influence the rest of the
> layout) ?
Yeah -- I'll file a followup and take a look soon.