This is what non-native menus do. document.popupNode is a very awkward API; it's
global state that gets updated from multiple places and which is hard to reason
about.
For that reason, I think it's safest to stick closely to what non-native menus
are doing. I'm not aware of any user-facing breakage that this patch fixes.
Differential Revision: https://phabricator.services.mozilla.com/D110303
This is more in line with how non-native popups are managed. The popup manager
knows about everything and is the source of any state changes, and it updates
the nsMenuPopupFrame when necessary.
Concretely, this change makes these two upcoming changes easier:
- "Rolling up" native context menus. The popup manager is the nsIRollupListener.
- Returning something sensible from nsXULPopupManager::GetLastTriggerNode while
a native context menu is open.
Differential Revision: https://phabricator.services.mozilla.com/D110300
This is macOS only and behind the prefs widget.macos.native-context-menus and
browser.proton.contextmenus.enabled .
The big design question here is: Where do we put the fork in the road? How much
should the existing non-native popup management machinery know about the state
of the native menu? Which parts of the non-native state should a) reflect the
true native state, b) enter a special "handled natively" state, or c) lie?
This patch picks the following approach:
- The nsMenuPopupFrame of the root menupopup knows about the native menu; it
keeps it alive in its new mNativeMenu field.
- If the context menu has submenus, i.e. nested <menupopup> elements, the
nsMenuPopupFrames for those nested menupopups do not know anything about the
native menu.
- The mPopupState of natively-handled nsMenuPopupFrames is ePopupClosed.
- XULPopupElement::GetState, which queries the frame's mPopupState, also
returns "closed". This might cause problems in the future.
- The XUL popup manager's mPopups "menu chain" does not know about any open
native menus.
- The rollup widget also does not know about the native popup.
I've chosen to use ePopupClosed for native menus for the following reasons:
1. While mirroring / updating the state for the root menu would be doable
without too much trouble, it would be much more annoying to do the same for
nested menupopups of submenus. So if submenus will be ePopupClosed, it's
consistent for the root menu to also be ePopupClosed.
2. nsXULPopupManager has assertions (for example in MayShowPopup) that make
sure that the menu popup frame's mPopupState is consistent with the XUL
popup manager's mPopups menu chain. Keeping the two both "closed" is the
easiest way to achieve consistency.
Unless there are grave concerns with this approach, I suggest we go with it for
now and see what trouble arises.
Differential Revision: https://phabricator.services.mozilla.com/D109183
The patch in bug 1666497 (which makes regular <window>-based XUL
documents with other the XHTML-based ones) uncovers an issue in the
anchored popup tests, which starts timing out.
The underlying issue is that it changes the reflow order from popups in
XUL-only documents with respect to their anchors. Note that Firefox
already uses the "broken" code, because we moved to xhtml and
browser.xhtml doesn't use a XUL <window> anymore.
Since we reflow now the popup _after_ the anchor rather than before, we
don't need to rely on CheckForAnchorChange() to deal with changes. This
means that we need to notify on the positioning changes that happen
during reflow though.
We should be able to simplify a bit the CheckForAnchorChange() stuff
now, but it also takes care of hiding popups and such so I don't plan to
do it on this bug to minimize risk.
Differential Revision: https://phabricator.services.mozilla.com/D91012
The patch in bug 1666497 (which makes regular <window>-based XUL
documents with other the XHTML-based ones) uncovers an issue in the
anchored popup tests, which starts timing out.
The underlying issue is that it changes the reflow order from popups in
XUL-only documents with respect to their anchors. Note that Firefox
already uses the "broken" code, because we moved to xhtml and
browser.xhtml doesn't use a XUL <window> anymore.
Since we reflow now the popup _after_ the anchor rather than before, we
don't need to rely on CheckForAnchorChange() to deal with changes. This
means that we need to notify on the positioning changes that happen
during reflow though.
We should be able to simplify a bit the CheckForAnchorChange() stuff
now, but it also takes care of hiding popups and such so I don't plan to
do it on this bug to minimize risk.
Differential Revision: https://phabricator.services.mozilla.com/D91012
The patch in bug 1666497 (which makes regular <window>-based XUL
documents with other the XHTML-based ones) uncovers an issue in the
anchored popup tests, which starts timing out.
The underlying issue is that it changes the reflow order from popups in
XUL-only documents with respect to their anchors. Note that Firefox
already uses the "broken" code, because we moved to xhtml and
browser.xhtml doesn't use a XUL <window> anymore.
Since we reflow now the popup _after_ the anchor rather than before, we
don't need to rely on CheckForAnchorChange() to deal with changes. This
means that we need to notify on the positioning changes that happen
during reflow though.
We should be able to simplify a bit the CheckForAnchorChange() stuff
now, but it also takes care of hiding popups and such so I don't plan to
do it on this bug to minimize risk.
Differential Revision: https://phabricator.services.mozilla.com/D91012
Converts `ui.menu.incremental_search.timeout` to a static pref and replaces macros related to the incremental search timeout with the actual pref, so that they are kept in sync without the need to manually update any macros. The two `.xml` files mentioned in the note were nowhere to be found, so this patch makes the assumption that those do not exist anymore and do not need to be kept in sync.
Differential Revision: https://phabricator.services.mozilla.com/D75182
If we want correct popup placement we need to use the right anchor rect
for gdk_window_move_to_rect under Wayland. Patch exports the anchor rect from the
nsMenuPopupFrame to be used in nsWindow.
This patch also fixes popup overflowing the screen by using the size returned from
gdk_window_move_to_rect for the nsMenuPopupFrame.
Differential Revision: https://phabricator.services.mozilla.com/D67810
If we want correct popup placement we need to use the right anchor rect
for gdk_window_move_to_rect under Wayland. Patch exports the anchor rect from the
nsMenuPopupFrame to be used in nsWindow.
This patch also fixes popup overflowing the screen by using the size returned from
gdk_window_move_to_rect for the nsMenuPopupFrame.
Differential Revision: https://phabricator.services.mozilla.com/D67810
If we want correct popup placement we need to use the right anchor rect
for gdk_window_move_to_rect under Wayland. Patch exports the anchor rect from the
nsMenuPopupFrame to be used in nsWindow.
This patch also fixes popup overflowing the screen by using the size returned from
gdk_window_move_to_rect for the nsMenuPopupFrame.
Differential Revision: https://phabricator.services.mozilla.com/D67810
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
It can return the root widget if the menu popup frame doesn't have a widget. None of the callers want this.
Differential Revision: https://phabricator.services.mozilla.com/D54258
--HG--
extra : moz-landing-system : lando
:ntim was about to add another widget-affecting property (pointer-events) to
menupopups to replace the mousethrough attribute, see bug 1597120.
But pointer-events is inherited, and thus changing pointer-events on any element
would cause a change list of length == the number of descendants of the element,
which is not amazing.
So I suggested using DidSetComputedStyle instead, as this is fairly
popup-specific, but we may as well be consistent and do the same everywhere.
This removes the code to handle the -moz-window-* properties on the root frame,
as I haven't seen any usage of them (we always set them in panel or menupopup).
Differential Revision: https://phabricator.services.mozilla.com/D53377
--HG--
extra : moz-landing-system : lando
It seems better to convert this before adding a new flag (in bug
1547759) and risking replacing the wrong 0 with a flag.
Differential Revision: https://phabricator.services.mozilla.com/D40562
--HG--
extra : moz-landing-system : lando
This code contains an undesirable dependency between the layout code and
the implementation of toolbarbutton. Since it isn't actually used anywhere
by the firefox UI, remove it here.
Differential Revision: https://phabricator.services.mozilla.com/D31939
--HG--
extra : rebase_source : 663776a71d658e782650e85c6c27716f0c8736d8
Unfortunately, `EventChainVisitor` does not grab the `nsPresContext` with
`RefPtr` by itself. Therefore, there is no guarantee of the lifetime without
checking the origin when its subclasses are instantiated. This patch changes
it and subclasses to `MOZ_STACK_CLASS` since only `EventDispatcher::Dispatch()`
creates them in the stack with given `nsPresContext`. Additionally, it's
already been marked as MOZ_CAN_RUN_SCRIPT_BOUNDARY`. Therefore, the
`nsPresContext` instance has already been guaranteed its lifetime by the
caller. For making this fact stronger, this patch marks their constructors
as `MOZ_CAN_RUN_SCRIPT`. Therefore, nobody can create those instances without
guaranteeing the lifetime of `nsPresContext` and `dom::Event`. Note that
it may look like that `mPresContext` of `EventChainPostVisitor` is not
guaranteed. However, `EventChainPreVisitor` which gives `nsPresContext` to it
is also a stack only class. So, it won't be deleted before
`EventChainPostVisitor` instance.
Differential Revision: https://phabricator.services.mozilla.com/D30010
--HG--
extra : moz-landing-system : lando
Additionally, this patch makes `nsContentUtils::DispatchXULCommand()` because
it guarantees the lifetime of **only** `PresShell` in it. So, we need to check
the lifetime of each argument at each caller here.
Differential Revision: https://phabricator.services.mozilla.com/D29199
--HG--
extra : moz-landing-system : lando
Wayland protocol allows to have only one popup window attached to a parent widget.
Recently we use a toplevel window widget as parent for all popups.
That means a second level menu (like File -> New Container Tab)
is not displayed as both ("File" and "New Container Tab" menus)
have the same parent widget.
As a solution allow to get the actual parent run-time and set that
when we open the window on toolkit level.
This patch covers menu widgets in the same frame hierarchy.
Differential Revision: https://phabricator.services.mozilla.com/D26112
--HG--
extra : moz-landing-system : lando
Additionally, this patch makes `nsFrame.h` stop including `nsIPresShell.h`
and makes each users include `mozilla/PresShell.h` instead. So, this improves
rebuild performance of `nsIPresShell.h` (and `mozilla/PresShell.h` in the
future).
Note that due to `nsIFrame::PresShell()`, `mozilla::` prefix is necessary for
`PresShell` in a lot of classes which are derived from `nsIFrame` even in
`.cpp` files.
Differential Revision: https://phabricator.services.mozilla.com/D27476
--HG--
extra : moz-landing-system : lando
It only works basically by chance with XBL and doesn't handle any kind of
dynamic insertion. See comment 4 in the bug for the diagnostic.
Differential Revision: https://phabricator.services.mozilla.com/D19489
--HG--
extra : moz-landing-system : lando
It only works basically by chance with XBL and doesn't handle any kind of
dynamic insertion. See comment 4 in the bug for the diagnostic.
Differential Revision: https://phabricator.services.mozilla.com/D19489
--HG--
extra : moz-landing-system : lando
All classes deriving from nsIFrame that did not have any subclasses themselves
(at the time of writing this patch) have been marked with `final`.
Some other Layout classes have also been made final, but this was opportunistic
while working on nsIFrame subclasses, and is definitely not exhaustive, further
patches welcome; refer to bug 1332680.
Advantages of marking a class final include:
- Allowing the compiler to devirtualize some method calls (i.e., calling
virtual functions directly instead of going through the vtable),
- Indicating that the class is not currently subclassed,
- Preventing subclassing without being aware that this would remove the
finalization benefits of the parent class.
`final` does not signify that these classes should *never* be subclassed, this
is left for developers to decide.
Differential Revision: https://phabricator.services.mozilla.com/D5020
--HG--
extra : moz-landing-system : lando
Markus Stange
Emilio Cobos Álvarez
Narcis Beleuzu
Csoregi Natalia
Simon Giesecke
Kristen Wright
Jan Horak
Mihai Alexandru Michis
Bogdan Tara
Gabriele Svelto
jeffin143
Timothy Nikkel
Razvan Maries
L. David Baron
Andrew Swan
Masayuki Nakano
Martin Stransky
Neil Deakin
Dorel Luca
Cameron McCormack
Sylvestre Ledru
Jonathan Watt
Gerald Squelart
Ting-Yu Lin
Andi-Bogdan Postelnicu
Sebastian Hengst
Dão Gottwald
Tristan Bourvon