What caused the issue was that nsMenuPopupFrame::MoveTo didn't account
for the change in bug 312891. But our context menu / popup positioning
code can be much simpler if we account for the context menu offset
before-hand as an extra horizontal / vertical margin in all directions.
Then we don't need to special-case it at all.
Differential Revision: https://phabricator.services.mozilla.com/D140263
What caused the issue was that nsMenuPopupFrame::MoveTo didn't account
for the change in bug 312891. But our context menu / popup positioning
code can be much simpler if we account for the context menu offset
before-hand as an extra horizontal / vertical margin in all directions.
Then we don't need to special-case it at all.
Differential Revision: https://phabricator.services.mozilla.com/D140263
Bug 1696718 landed a fix to propagate the position change from layout.
However that's not correct, because the widget isn't resized until
nsView::ProcessPendingUpdatesForView is resized (and even that in some
platforms it might be async).
So the right place to propagate the position change is in
nsXULPopupManager (which we call into from the view system which listens
itself to the widget).
Let's try to enable the test for that bug everywhere with this fixed.
Differential Revision: https://phabricator.services.mozilla.com/D127801
Make sure it's always in sync with the style.
Keeping a boolean field was useful when we didn't handle dynamic changes
to it, but now we do it's just redundant, and could cause correctness
issues.
Differential Revision: https://phabricator.services.mozilla.com/D124081
We have to use wayland to position popup windows and we need to propagate the modified
position (if happens) back to nsView. The mScreenRect in the nsMenuPopupFrame is in the CSS units
and that produce rounding error when font scale factor is not 1. To fix that we will use appunits
for the mScreenRect.
Differential Revision: https://phabricator.services.mozilla.com/D114577
This involves changing moveToAnchor to be allowed while the popup is showing. This change allows the buttons within the tab to use the normal algorithm for determining the tooltip position. This also fixes bug 1695900 so that tooltips for items in bookmarks menus also appear offset as well. Only the main tab and bookmarks on the toolbar appear aligned with the button's bottom edge.
Differential Revision: https://phabricator.services.mozilla.com/D115558
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
Emilio Cobos Álvarez
Noemi Erli
stransky
Kagami Sascha Rosylight
Iulian Moraru
Neil Deakin
Markus Stange
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