The modifications are all straightforward conversion except the one in
nsMathMLContainerFrame, where it is simplified by calling the equivalent
BuildDisplayListForInline() helper.
Differential Revision: https://phabricator.services.mozilla.com/D78166
Add the NSWindowCollectionBehaviorMoveToActiveSpace behavior to nsCocoaWindow
popups so that they override the "Assign To" space setting and display on the
active space.
This also addresses bug 1589893 where, when "Assign To" space is used, popup
menus are not visible in full screen mode.
With mutiple displays, recreate the popup widget each time it is displayed
to workaround a problem where the re-shown popup appears on the "Assign To"
display instead of the current display.
Differential Revision: https://phabricator.services.mozilla.com/D75419
Add the NSWindowCollectionBehaviorMoveToActiveSpace behavior to nsCocoaWindow
popups so that they override the "Assign To" space setting and display on the
active space.
This also addresses bug 1589893 where, when "Assign To" space is used, popup
menus are not visible in full screen mode.
With mutiple displays, recreate the popup widget each time it is displayed
to workaround a problem where the re-shown popup appears on the "Assign To"
display instead of the current display.
Differential Revision: https://phabricator.services.mozilla.com/D75419
There's no use case for stateful comparators, so they can be just plain
function pointers.
This is used in some hot places like CSS selector matching.
Differential Revision: https://phabricator.services.mozilla.com/D77084
Add the NSWindowCollectionBehaviorMoveToActiveSpace behavior to nsCocoaWindow
popups so that they override the "Assign To" space setting and display on the
active space.
This also addresses bug 1589893 where, when "Assign To" space is used, popup
menus are not visible in full screen mode.
With mutiple displays, recreate the popup widget each time it is displayed
to workaround a problem where the re-shown popup appears on the "Assign To"
display instead of the current display.
Differential Revision: https://phabricator.services.mozilla.com/D75419
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
This patch is generated by using my editor's rename functionality.
In the next patch, `nsIFrame::` prefix is going to be removed manually
from all the ChildLists() calls.
Differential Revision: https://phabricator.services.mozilla.com/D75893
We have to compare new width and height multiplied by scale because mBounds is in
real pixels while gdk_window_move_to_rect returns the size without multiplying
by scale factor.
Also to fix overflow popups we need to use NativeMoveResize in nsWindow::ResizeInt
when size of the popup has changed.
Differential Revision: https://phabricator.services.mozilla.com/D75298
Chrome inserts shadow dom lazily during that event, which can make us
reconstruct the menupopup temporarily.
When lazyfc is disabled we reconstruct it immediately so this code gets
a non-null primary frame, but with it enabled we need to flush frames.
Do the same in popuphiding for consistency.
Differential Revision: https://phabricator.services.mozilla.com/D74887
The place where it's done right now is just unsound. It modifies
attributes during frame construction and it causes assertions to fire
with lazy frame-construction enabled.
Differential Revision: https://phabricator.services.mozilla.com/D74029
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
We need it to live in BrowsingContext instead of WindowContext, because
we need to preserve the zoom level across same-origin navigation.
It'd be nice if it only lived in the top BC, but that's not possible at
the moment because a lot of tests rely on zooming only iframes. Some of
them can be adjusted for scaling the top instead, but not sure it's
worth it's worth fixing them and moving the zoom to be top-only, as it'd
be a bunch of effort, and the complexity and overhead of propagating the
zoom is not so big.
The print-preview-specific code in nsContentViewer is from before we did
the document cloning setup, and it seems useless. I've tested print
preview scaling before and after my patch and both behave the same.
The rest is just various test changes to use the SpecialPowers APIs or
BrowsingContext as needed instead of directly poking at the content
viewer.
I named the pres context hook RecomputeBrowsingContextDependentData, as
more stuff should move there like overrideDPPX and other media emulation
shenanigans.
I also have some ideas to simplify or even remove ZoomChild and such,
but that's followup work.
Differential Revision: https://phabricator.services.mozilla.com/D71969
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
Kinda drive-by, but I think this is sane and not risky... This is used for
<select size> / <select multiple>, and only scrolls the option into view (it
only scrolls a single scroll frame, the one inside the <select>).
If the author specifies scroll-padding / margin in there I don't see why we
shouldn't respect it when doing key selection / navigation / etc.
Same for menupopups (though those are even less risky because we control the CSS
there).
Differential Revision: https://phabricator.services.mozilla.com/D70543
--HG--
extra : moz-landing-system : lando
Converts `ui.key.menuAccessKeyFocuses` to a static pref and removes `nsMenuBarListener::InitializeStatics()`. This pref sets to `true` in windows and linux, which may affect behavior in SeaMonkey and Thunderbird.
Differential Revision: https://phabricator.services.mozilla.com/D69617
--HG--
extra : moz-landing-system : lando
On Mac, ctrl-click will send a context menu event from the widget, so we don't
want to bring up the panel when ctrl key is pressed.
Differential Revision: https://phabricator.services.mozilla.com/D66439
--HG--
extra : moz-landing-system : lando
This was generated with
```
cp .gitignore .rgignore
rg -l -g '*.{html,xhtml}' 'href="chrome://global/skin/"' | xargs sed -i "" 's/href\="chrome:\/\/global\/skin\/"/href\="chrome:\/\/global\/skin\/global.css"/g'
```
Differential Revision: https://phabricator.services.mozilla.com/D67687
--HG--
extra : moz-landing-system : lando
Ting-Yu Lin
Razvan Maries
Kris Maglione
Haik Aftandilian
Emilio Cobos Álvarez
Sylvestre Ledru
Butkovits Atila
Kristen Wright
Jan Horak
Hiroyuki Ikezoe
Coroiu Cristina
Miko Mynttinen
sotaro
Kagami Sascha Rosylight
Narcis Beleuzu
Botond Ballo
Cosmin Sabou
Csoregi Natalia
Simon Giesecke
Mihai Alexandru Michis
Shyam Sundar
Edgar Chen
Brian Grinstead