Bug 1870512 removed top level windows with WindowType::Popup, instead
replacing it with an "alert" feature for the only use of them that we
had.
Turns out that on Windows they need a bit more special handling than I
thought, so this patch uses the alert boolean to fix two regressions
(that alerts now create taskbar icons, and that they steal focus).
Remove mIsForMenuPopupFrame since that is now a synonym with
WindowType::Popup.
Remove also the dialog vs. toplevel difference of using
WS_EX_DLGMODALFRAME, since that doesn't seem to have an effect at all on
windows 10+.
Differential Revision: https://phabricator.services.mozilla.com/D200508
This adds proper borders and radii on Windows and Linux, which are
otherwise not present, and simplifies a bit the code by using the same
code path across platforms, and between HTML and XUL.
Remove some ::-moz-focus-inner styles which no longer apply to un-themed
buttons.
The extra -0.5 offset I think was compensating for the margins and
missing border-box sizing.
Differential Revision: https://phabricator.services.mozilla.com/D197793
Before the first part of bug 1872399, that would use
WindowShadow::Default, which didn't create a vibrant effect etc, which
causes the background here.
Make it more explicit by calling this "Panel". The second part of
bug 1872399 already did this.
Differential Revision: https://phabricator.services.mozilla.com/D197648
-moz-window-shadow is a chrome-only property (not exposed to the web),
and chrome stylesheets only use the none value to disable the default
behavior.
Split the style property (default/none) from the actual widget behavior.
This is useful because I want to add a distinction between
natively-styled menupopups and other panels in the following commit.
While at it rename default to "auto" which is a more common name in CSS
for something like this.
We have no use case for removing the shadow of a top-level window, so
remove it to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D197454
This is probably testable, but I don't know how we'd make the test
reliable (we haven't found particularly reliable STR yet, see comments).
Differential Revision: https://phabricator.services.mozilla.com/D193827
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
To avoid trying to render a huge popup before move-to-rect finishes.
Not quite convince we want this but should fix this.
Differential Revision: https://phabricator.services.mozilla.com/D187824
This is an edge case where layout thinks the popup doesn't need
flipping, but the compositor does.
In an ideal world we'd convince the compositor it doesn't by providing
our margins, but that doesn't seem easily doable.
So check whether there was a constraint rect that we tried to honor
instead, rather than whether we actually had to flip or what not.
Differential Revision: https://phabricator.services.mozilla.com/D187823
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
We had these spread around, it's better to have a single central place where we
update the widget based on the styling of the popups.
Differential Revision: https://phabricator.services.mozilla.com/D173836
Otherwise we lose the anchor constraints which can change our layout.
The only thing we want is to stop following the anchor _node_, so we can
just convert it to an anchor rect instead.
Differential Revision: https://phabricator.services.mozilla.com/D173135
The underlying issue here is an invalidation bug with XUL layout. When a
popup opens, we try to lay it out at full size, then post a reflow
callback to constrain it.
There's an intermediate step there where the popup might remain at full
size, and the constraining operates directly on mRect, which isn't quite
sound and doesn't update the scrollport of descendants.
Make nsMenuPopupFrame inherit from nsBlockFrame instead, doing
potentially two layout passes when constrained.
This fixes the issue at hand, and removes XUL layout from menu popups,
so it's a win-win.
To make reasoning about it a bit easier, factor out a bunch of the XUL
positioning code to be const. The mutation of mRect etc which was going
on otherwise was pretty hard to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D170368
This ended up being a lot more straight-forward than the menu changes.
TLDR:
* nsMenuBarFrame -> XULMenuBarElement
* nsMenuBarListener -> MenuBarListener
Rest should be rather straight-forward.
Depends on D168649
Differential Revision: https://phabricator.services.mozilla.com/D167809
This ended up being a lot more straight-forward than the menu changes.
TLDR:
* nsMenuBarFrame -> XULMenuBarElement
* nsMenuBarListener -> MenuBarListener
Rest should be rather straight-forward.
Depends on D168649
Differential Revision: https://phabricator.services.mozilla.com/D167809
I'm about to extend them for bug 1811486, where I want to force in some
cases the rolled up popups to hide synchronously. These APIs use a ton
of boolean arguments that make them error prone, so refactor them a bit
to use strongly typed enums and flags.
Differential Revision: https://phabricator.services.mozilla.com/D167381
Move it to the mozilla::widget namespace.
Use enum classes for transparency, popup type, popup level, etc.
Mostly automated with sed, but there were a few manual changes required
as well in windows code because they relied on Atomic<TransparencyMode>
working (which now doesn't because TransparencyMode is 1 byte instead of
4 bytes).
Differential Revision: https://phabricator.services.mozilla.com/D167537
I'm about to extend them for bug 1811486, where I want to force in some
cases the rolled up popups to hide synchronously. These APIs use a ton
of boolean arguments that make them error prone, so refactor them a bit
to use strongly typed enums and flags.
Differential Revision: https://phabricator.services.mozilla.com/D167381
I'm about to extend them for bug 1811486, where I want to force in some
cases the rolled up popups to hide synchronously. These APIs use a ton
of boolean arguments that make them error prone, so refactor them a bit
to use strongly typed enums and flags.
Differential Revision: https://phabricator.services.mozilla.com/D167381
Move most the event handling stuff to the DOM. I've left nsMenuBarFrame
for now, but I will be removing that in the future.
The basic set up is:
* nsMenuParent becomes XULMenuParentElement (menubar or popup, manages
the current active menu item)
* nsMenuFrame -> XULButtonElements that return true for IsMenu().
Can't use XULMenuElement because of <button type=menu>, which
behaves like a, well, menu.
This makes the a11y events for menus (DOMMenuItem{Active,Inactive}) make
sense (before that we were firing duplicate Inactive events etc, and the
event order was rather suspicious).
Differential Revision: https://phabricator.services.mozilla.com/D164210
Move most the event handling stuff to the DOM. I've left nsMenuBarFrame
for now, but I will be removing that in the future.
The basic set up is:
* nsMenuParent becomes XULMenuParentElement (menubar or popup, manages
the current active menu item)
* nsMenuFrame -> XULButtonElements that return true for IsMenu().
Can't use XULMenuElement because of <button type=menu>, which
behaves like a, well, menu.
This makes the a11y events for menus (DOMMenuItem{Active,Inactive}) make
sense (before that we were firing duplicate Inactive events etc, and the
event order was rather suspicious).
Differential Revision: https://phabricator.services.mozilla.com/D164210
HTMLSelectEventListener changes are needed, since currently that code works somewhat by accident given that
mTime often contains totally bogus values, like PR_IntervalNow(). Those changes then reveal issues also in
browser_editAddressDialog.js.
Differential Revision: https://phabricator.services.mozilla.com/D165618
See the comment for why we can't just use scrollbar-gutter: stable,
which is what we'd want, ideally.
This is reproducible on Win10 and also Linux as long as:
* Overlay scrollbars are disabled.
* The scrollbar size is bigger than the menulist arrow size.
This used to be done by the chunk of code here:
* 8f61a444ce (l7.82)
Which changed the size of the menu (not just the popup) which then the
popup expanded to. So quite hacky over-all.
Differential Revision: https://phabricator.services.mozilla.com/D165669
I decided to split this up from bug 1805414 because it's only
tangentially related to the removal of nsMenuFrame.
We have this sizetopopup attribute and behavior that allows menulists to
be sized to the contents of the popup. The popup also expands to the
menulist rect.
This means that layout is by somewhat cyclic and we need to go out of
our way to support it. However, I think we only care about the first
behavior. We don't have many non-intrinsically-sized menulists, and
if we need we can use HTML <select> instead, which does have that
behavior.
Simplify the setup to make sizetopopup only apply to menulists (we don't
have non-menulist usage anyways), and only work in the "popup depends on
the menulist" direction, not the other way around.
This will allow making the popup a regular out-of-flow element. The
change to test_menulist_paging is not needed (I restored the behavior of
eagerly layout menulists, to fix the <select> popup, but I'd like to fix
that eventually, so I'd rather leave them in, they're harmless).
Differential Revision: https://phabricator.services.mozilla.com/D164693
My guess is that it was done using shadows to not interfere with the
native look, but actually this just works even with native-looking menus
(like the <select> menulist), because the background-color for those is
set on the menupopup, rather than the ::part(content).
So those have effectively 1px of extra padding (due to the transparent
border), but that seems barely perceptible, and worth the consistency
and simplification.
Differential Revision: https://phabricator.services.mozilla.com/D164716
My guess is that it was done using shadows to not interfere with the
native look, but actually this just works even with native-looking menus
(like the <select> menulist), because the background-color for those is
set on the menupopup, rather than the ::part(content).
So those have effectively 1px of extra padding (due to the transparent
border), but that seems barely perceptible, and worth the consistency
and simplification.
Differential Revision: https://phabricator.services.mozilla.com/D164716
My guess is that it was done using shadows to not interfere with the
native look, but actually this just works even with native-looking menus
(like the <select> menulist), because the background-color for those is
set on the menupopup, rather than the ::part(content).
So those have effectively 1px of extra padding (due to the transparent
border), but that seems barely perceptible, and worth the consistency
and simplification.
Differential Revision: https://phabricator.services.mozilla.com/D164716
I decided to split this up from bug 1805414 because it's only
tangentially related to the removal of nsMenuFrame.
We have this sizetopopup attribute and behavior that allows menulists to
be sized to the contents of the popup. The popup also expands to the
menulist rect.
This means that layout is by somewhat cyclic and we need to go out of
our way to support it. However, I think we only care about the first
behavior. We don't have many non-intrinsically-sized menulists, and
if we need we can use HTML <select> instead, which does have that
behavior.
Simplify the setup to make sizetopopup only apply to menulists (we don't
have non-menulist usage anyways), and only work in the "popup depends on
the menulist" direction, not the other way around.
This will allow making the popup a regular out-of-flow element. The
change to test_menulist_paging is not needed (I restored the behavior of
eagerly layout menulists, to fix the <select> popup, but I'd like to fix
that eventually, so I'd rather leave them in, they're harmless).
Differential Revision: https://phabricator.services.mozilla.com/D164693
This reduces the weird interactions that can appear on menus.
This also progresses BiDi support, including for accesskeys.
Differential Revision: https://phabricator.services.mozilla.com/D161498
