This makes alert take the same area as the status panel, partially
backing out the regressing bug.
.browserStack is also relatively-positioned, so this works too. I think
I didn't realize this while writing bug 1791972 because the rule was in
a UA sheet (all <stack>s are relatively positioned, apparently).
This restores the behavior when devtools is toggled vertically. On
responsive mode this still covers the top toolbar, but that was the
pre-existing behavior. Could be fixed in a follow-up with some z-index
tweaking...
Differential Revision: https://phabricator.services.mozilla.com/D162739
* Make non-menulist popups just absolute positioned top-layer items.
* Simplify menulist popups to just be static-positioned items under
nsMenuFrame.
We need to keep kPopupList only for nsMenuFrame. In the future it can be
removed, see TODO in xul.css
Differential Revision: https://phabricator.services.mozilla.com/D161404
* Make non-menulist popups just absolute positioned top-layer items.
* Simplify menulist popups to just be static-positioned items under
nsMenuFrame.
We need to keep kPopupList only for nsMenuFrame. In the future it can be
removed, see TODO in xul.css
Differential Revision: https://phabricator.services.mozilla.com/D161404
Long ago, the menu panel in was a customizable area that users could drag things into.
That changed back around 2017 in bug 1354117 when the Photon redesign was built. The
menu panel become a static menu, but we also made it possible to permanently move things
to the overflow panel of the nav-bar.
It looks like we never updated the area type constant from referring to the old menu panel
though, so it's "TYPE_MENU_PANEL", and registering a node for it happens with
registerMenuPanel. This patch changes to constant to TYPE_PANEL and updates the registration
method to registerPanelNode.
I a check around the codebase as well as GitHub looking to see if there were any
system add-ons or experimental WebExtensions that rely on TYPE_MENU_PANEL / registerMenuPanel,
but I couldn't find any.
Differential Revision: https://phabricator.services.mozilla.com/D161078
If the user has a lot of bookmarks, there's a point in time where we're
computing the overflow menu arrow position, but we still haven't removed
the bookmark items from the toolbar.
This causes a wrong offset to be computed, because -moz-fit-content
computes a very large width to fit all the bookmarks.
In general, -moz-fit-content can cause stuff to overflow the browser
window (this didn't happen before modern flexbox because XUL didn't
respect min-width so aggressively). This comes from bug 993299 and I
believe we could get rid of it.
At least I don't think it has an effect on actual window width anymore,
because the ConvertsToLength() check doesn't pass here:
https://searchfox.org/mozilla-central/rev/3c194fa1d6f339036d2ec9516bd310c6ad612859/layout/generic/nsContainerFrame.cpp#819-821
This is true at least since we switched to <html> root for
browser.xhtml.
Differential Revision: https://phabricator.services.mozilla.com/D161453
Use resizebefore/after=sibling to avoid setting the width of anything
else that isn't the DevTools frame, and make the size not impose a min
size to allow it to shrink.
Differential Revision: https://phabricator.services.mozilla.com/D161058
There was only a min-height: 0 missing. I also cleaned-up a bit because
flex: 1 is the same as flex: 1 1 auto, and flex attribute (which only
sets -moz-box-flex) is not doing anything because it was inside flex
layout (so legacy properties aren't looked at).
Differential Revision: https://phabricator.services.mozilla.com/D160094
This depends on bug 1795892 and restores the sizing behavior that XUL had for
this case (making the overflow: hidden element not contribute to the intrinsic
size of the container).
If this were to be written today, we couldd probably use absolute positioning
or transforms, and maybe this could be simplified a bit. This is the less risky
change tho.
Differential Revision: https://phabricator.services.mozilla.com/D159639
The min-width / contain are as usual to allow elements to shrink under
their intrinsic size. You can only see its effects with relatively thin
windows (or with a very large number of tabs in the tabstrip case).
Differential Revision: https://phabricator.services.mozilla.com/D157216
For that, we need to min-width: 0 the nav-bar target, which itself
requires us to tweak the overflow detection so that we look at all
children of the customization target, not only the target itself.
Differential Revision: https://phabricator.services.mozilla.com/D159377
The min-width / contain are as usual to allow elements to shrink under
their intrinsic size. You can only see its effects with relatively thin
windows (or with a very large number of tabs in the tabstrip case).
Differential Revision: https://phabricator.services.mozilla.com/D157216
This matches the old XUL behavior. Note that this is fixed by bug
1790616, but we probably don't want to depend on that.
Differential Revision: https://phabricator.services.mozilla.com/D158948
This patch adds some space after the menu button in the toolbar, which
makes things a lot better on MacOS and I noticed a small improvement on
Windows too.
Differential Revision: https://phabricator.services.mozilla.com/D158138
.browserContainer is relatively positioned, so we can position the
tab-modal dialogs absolutely inside it instead of making them part of
the browser stack.
While at it, make the rdm toolbar part of the regular browserContainer,
just like the regular devtools toolbox is. That way there's no need to
do ResizeObserver shenanigans to be able to let it grow. Keep it also
absolutely positioned tho, because we need to overlay the whole
container when the device modal is opened. That's somewhat gross.
This should in general be simpler to understand than the current set-up,
and more performant to since it avoids the dialog stack from forming
part of the browser element's flow.
Differential Revision: https://phabricator.services.mozilla.com/D157912
Create XULButtonElement instead to do the event handling. Pretty much a
straight port, this allows these elements to respect CSS display
properly (and use modern flexbox rather than old XUL layout).
Differential Revision: https://phabricator.services.mozilla.com/D157509
This patch also adjusts some `min-width` rules like it was done for the
downloads button. It should work with either buttons OR both, which is
going to happen since the unified extensions button will be most likely
always visible in the toolbar.
Differential Revision: https://phabricator.services.mozilla.com/D154360
Most of the display: block stuff isn't needed anymore because we changed
the blockification behavior in bug 1789123.
.tab-stack, and stacks in general now uses CSS grid so doesn't need that
anymore.
DevTools is the only consumer of <xul:iframe> and width/height was
getting ignored in XUL because flexibility takes precedence, so just
remove the relevant declarations.
Differential Revision: https://phabricator.services.mozilla.com/D157070
Trivial test-case: data:text/html,<script>alert("foo")</script>
The dialog grows because of the grid container, and -moz-box prefers
honoring flexibility to the explicit height, so this declaration is
useless.
Emulated flexbox actually honors it and crops the dialog. Just remove
it.
Differential Revision: https://phabricator.services.mozilla.com/D157069
Make the dialog frame for Spotlight modal dialogs cover the full window,
prevent the fixed sizing in SubDialog for these dialogs, and vertically
center the dialog relative to its frame. Make the scrollport accommodate
the full Spotlight so it can be scrolled, without wasting any scroll
distance on margins. So, the top margin will shrink with the window,
like the other margins do.
Differential Revision: https://phabricator.services.mozilla.com/D156127
Make the dialog frame for Spotlight modal dialogs cover the full window,
prevent the fixed sizing in SubDialog for these dialogs, and vertically
center the dialog relative to its frame. Make the scrollport accommodate
the full Spotlight so it can be scrolled, without wasting any scroll
distance on margins. So, the top margin will shrink with the window,
like the other margins do.
Differential Revision: https://phabricator.services.mozilla.com/D156127
I'm a bit baffled about bug 1789877. My best theory so far is that we're
inserting the element a bit deeper in the DOM and that causes us to
reflow slightly more stuff when tab-switching, but...
In any case while going through the code the status panel can be
simplified a bit now, so do that.
Differential Revision: https://phabricator.services.mozilla.com/D156876
Updated SubDialog.jsm's sizeTo=available to have better support for responsive layouts with the ability to specify max height and widths on the dialog.
Differential Revision: https://phabricator.services.mozilla.com/D155014
Right now, the vertical position of the status panel is the "auto"
position, which ends up working out, but mostly by chance, and relies on
behavior that's different from the standard flexbox, see bug 1789165.
Instead of using `position: fixed` and relying on not having any
sidebars or other content to the inline-end (otherwise the [mirror] rule
would be incorrect), explicitly position it against the
.browserContainer.
Differential Revision: https://phabricator.services.mozilla.com/D156384
This doesn't change behavior by default but makes the menubar not show
up when emulating legacy flexbox
(layout.css.moz-box-flexbox-emulation.enabled=true).
Differential Revision: https://phabricator.services.mozilla.com/D156374
