It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
Panels don't rely so much on the popup manager code to deal with
menuitems etc, so this is trivial and fixes the issue as reported.
I think it's pretty unlikely to have animated stuff in menulists /
menupopups, so this should get us most of the way.
Differential Revision: https://phabricator.services.mozilla.com/D105550
When opening a native context menu with ctrl+click, the mousedown initiates drag
tracking. Then the menu opens. Native menus consume all mouse events, including
the upcoming mouseup event. This means that Gecko never sees the mouseup event
for the ctrl+click, so drag tracking stays active. Once the menu closes, the
next mouse event can be a long distance away from the ctrl+click's mousedown
position, so Gecko may initiate an unintended drag.
So we manually cancel drag tracking before opening the menu.
Differential Revision: https://phabricator.services.mozilla.com/D114795
Since bug 1717726 we've disallowed having remote <browser> or remote <iframe>
inside nsDeckFrame which means `captureingFrame` in ClearMouseCapture(nsIFrame*)
function will never be called in an out-of-process thus we can use
IsAncestorFrameCrossDocInProcess there.
Also add an assertions that the function gets called only with a child frame of
nsDeckFrame since this function is used only inside nsDeckFrame.
Depends on D119068
Differential Revision: https://phabricator.services.mozilla.com/D119069
The background to have this assertion is that nsDeckFrame::HideBox calls
PresShell::ClearMouseCapture and ClearMouseCapture checks whether the
being-hidden panel has a content capturing mouse events or not but the check
doesn't work if the content is in a remote process. In our current
mozilla-central tree, there is no such nsDeckFrame other than our browser's
tab. In the case of our browser's tab when switching tabs, i.e. hiding an
active tab, clearing the mouse capturing state has (should have) worked since
E10S (Note for Fission cases it has worked since bug 1680405). So, because
nsDeckFrame will be obsoleted sooner or later, we disallow the situation
for other cases instead of adding special handling for the other case.
Differential Revision: https://phabricator.services.mozilla.com/D119067
- Clear mAdjustOffsetForContextMenu at nsMenuPopupFrame when running on Wayland and use move-to-rect to produce the offset.
- Implement nsWindow::WaylandPopupIsContextMenu()
- Use mBonuds directly in NativeMoveResizeWaylandPopupCallback() instead of Gtk query.
- Add some more loggin and code polishing.
Differential Revision: https://phabricator.services.mozilla.com/D117283
- Clear mAdjustOffsetForContextMenu at nsMenuPopupFrame when running on Wayland and use move-to-rect to produce the offset.
- Implement nsWindow::WaylandPopupIsContextMenu()
- Use mBonuds directly in NativeMoveResizeWaylandPopupCallback() instead of Gtk query.
- Add some more loggin and code polishing.
Differential Revision: https://phabricator.services.mozilla.com/D117283
Instead of using a framescript, change promiseFocus to use the SpecialPowers actor. In addition, promiseFocus may now take a browsing context to focus a specific subframe's window. If that subframe is deeply nested, messages will be passed back and forth between the parent and each successive subframe to get to the one subframe that is desired to be focused. Similarly, this process is used when focusing a higher level frame that already has its focused element set to a subframe.
Differential Revision: https://phabricator.services.mozilla.com/D116387
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
Share the concept of a panel content with all other menupopups / panels.
This avoids importing global.css in the shadow tree, and renames the
arrowcontent part to just "content", since we want to introduce a
"content" part for other panels.
This shouldn't change behavior but makes bug 1708136 a matter of
tweaking a couple CSS rules and fixing up test failures.
Differential Revision: https://phabricator.services.mozilla.com/D113990
Share the concept of a panel content with all other menupopups / panels.
This avoids importing global.css in the shadow tree, and renames the
arrowcontent part to just "content", since we want to introduce a
"content" part for other panels.
This shouldn't change behavior but makes bug 1708136 a matter of
tweaking a couple CSS rules and fixing up test failures.
Differential Revision: https://phabricator.services.mozilla.com/D113990
In my investigation, `F4` key in the search bar may not be handled as expected
because if it happens, the popup's state stays "closed" and "popupshowing",
"popuphiding" nor "popuphidden" event is fired.
The scope of the test is checking IME enabled state in searchbar in some
situations. Therefore, failing to open the popup with `F4` key is out of
scope of the test. So, let's make it retry to open the popup in the case.
Differential Revision: https://phabricator.services.mozilla.com/D114571
This creates a new leaf nsDisplayWrapper item for consumers that just want an empty wrapper, with a Paint method that asserts. This lets us leaves Paint pure-virtual on nsDisplayWrapList, and lets the compiler force us to implement it for the other leaf types.
It also disables flattening of transform/opacity items. This is because they flatten the items even when used with FlattenedDisplayItemIterator, even though this doesn't add markers to replace them (only FLB does this). We could in theory fix this, but I don't think FLB performance matters much any more.
Differential Revision: https://phabricator.services.mozilla.com/D114676
This creates a new leaf nsDisplayWrapper item for consumers that just want an empty wrapper, with a Paint method that asserts. This lets us leaves Paint pure-virtual on nsDisplayWrapList, and lets the compiler force us to implement it for the other leaf types.
It also disables flattening of transform/opacity items. This is because they flatten the items even when used with FlattenedDisplayItemIterator, even though this doesn't add markers to replace them (only FLB does this). We could in theory fix this, but I don't think FLB performance matters much any more.
Differential Revision: https://phabricator.services.mozilla.com/D114676
This patch has no functional change beyond changing prototypes and
adding storage for ImageIntRegion for each ImageContainer.
Differential Revision: https://phabricator.services.mozilla.com/D114984