Otherwise, it changes the move-to-rect inputs, which can change the
output as well, making us move the anchor all the way to the right.
You could, I guess, consider this a mutter bug of sorts, because it
feels weird that you pass it an anchor that has been a `move-to-rect`
output and you get another rect as an output.
But also, it's kinda silly that we're doing that to begin with, so avoid
it by telling the popup frame whether it's been positioned / moved by
move-to-rect (and keeping the anchor in that case).
The reason this works on my setup without "Large text" is just dumb luck
(the front-end computes a max-height for the panel that is small enough
to fit on the screen).
Differential Revision: https://phabricator.services.mozilla.com/D155406
Otherwise, it changes the move-to-rect inputs, which can change the
output as well, making us move the anchor all the way to the right.
You could, I guess, consider this a mutter bug of sorts, because it
feels weird that you pass it an anchor that has been a `move-to-rect`
output and you get another rect as an output.
But also, it's kinda silly that we're doing that to begin with, so avoid
it by telling the popup frame whether it's been positioned / moved by
move-to-rect (and keeping the anchor in that case).
The reason this works on my setup without "Large text" is just dumb luck
(the front-end computes a max-height for the panel that is small enough
to fit on the screen).
Differential Revision: https://phabricator.services.mozilla.com/D155406
If the tooltip node and the target node are in different documents, we'd
use the tooltip's CSS-to-dev-pixel scale to convert.
This is basically bug 1756323 but for XUL, I thought we wouldn't have
cross-document zoom like that but apparently I was wrong...
Differential Revision: https://phabricator.services.mozilla.com/D148402
This preserves the previous behavior, though arguably we shouldn't call OpenMenu
to begin with if the menu has been rolled up.
Differential Revision: https://phabricator.services.mozilla.com/D138637
There's only one caller of it and it's not sound: The runnable captures a
raw frame pointer etc. Instead, just do a dispatch to the main thread
and call OpenMenu there. This simplifies the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D131082
There's only one caller of it and it's not sound: The runnable captures a
raw frame pointer etc. Instead, just do a dispatch to the main thread
and call OpenMenu there. This simplifies the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D131082
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 fix makes the following tests pass with native context menus:
- browser/base/content/test/contextMenu/browser_contextmenu_iframe.js
- browser/base/content/test/contextMenu/browser_contextmenu_linkopen.js
Depends on D112274
Differential Revision: https://phabricator.services.mozilla.com/D112275
This fixes tests which query popupElement.state.
Only the "root" menupopup is updated; the state for submenus is still always "closed".
Depends on D110973
Differential Revision: https://phabricator.services.mozilla.com/D110974
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
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
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
`UIEvent::GetRangeParent()` retrieves `nsIContent` instance but it needs to
return `already_AddRefed<nsINode>` because of a WebIDL method. However,
`nsIContent` is better type in C++ code. Therefore, this patch renames it
to `UIEvent::GetRangeParentContent()` and makes new `UIEvent::GetRangeParent()`
and just call it.
Additionally, some callers call `UIEvent::RangeOffset()` too, but that means
that they compute same things twice because both of them use
`nsLayoutUtils::GetContainerAndOffsetAtEvent()` with same input arguments.
Thus, `UIEvent::GetRangeParentContent()` should also return offset with optional
out argument. (Note that this does not make `RangeOffset()` use
`GetRangeParentContent()` because using out parameter for range parent causes
unnecessary computation cost for `RangeOffset()`.)
Therefore, finally, `UIEvent::GetRangeParentContent()` becomes also an alias of
raw method `UIEvent::GetRangeParentContentAndOffset()` which also returns offset
with out argument.
Differential Revision: https://phabricator.services.mozilla.com/D60095
--HG--
extra : moz-landing-system : lando
