When a tree row in the sidebar is selected, the background of that selected row
is styled with `-moz-appearance: -moz-mac-(active-)source-list-selection`.
We have two ways of rendering such selections:
1. With vibrancy, on 10.10+ if the sidebar itself uses vibrancy, and
2. With a solid fill, on 10.9 or if the sidebar itself does not use vibrancy.
In the Firefox main browser window, sidebar styling crosses document boundaries.
```
<hbox id="browser">
<vbox id="sidebar-box"> <-- this one has -moz-appearance: -moz-mac-source-list (or not)
<browser> (bookmarksSidebar.xhtml or historySidebar.xhtml)
<window>
<tree> <-- this contains the tree body frame which renders the tree contents,
including the selection backgrounds
```
We detect whether "the sidebar itself uses vibrancy" by walking up the frame tree
and looking for a frame with `-moz-appearance: -moz-mac-source-list`.
In the past, this lookup was inconsistent between nsTreeBodyFrame.cpp and theme rendering,
and it stopped at document boundaries. This patch makes the implementations more
consistent and allows it to cross document boundaries.
The old code only worked with the given DOM structure because `-moz-appearance: -moz-mac-source-list`
was repeated on the <tree> element. I'd like to remove that duplication.
The new code works correctly if `-moz-appearance: -moz-mac-source-list` is only set
on <vbox id="sidebar-box"> and not repeated on the tree.
Depends on D51465
Differential Revision: https://phabricator.services.mozilla.com/D78924
This patch was largely automated. It was generated by manually
editing .eslintrc.js and then running mach eslint layout --fix.
Additionally, this includes manual changes to test_bug533845.xhtml
and test_bug467442.xhtml that were necessary to appease eslint.
Differential Revision: https://phabricator.services.mozilla.com/D78615
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
Kris Maglione
Markus Stange
Razvan Maries
Dorel Luca
Emilio Cobos Álvarez
Timothy Nikkel
Kenrick
Ting-Yu Lin
Haik Aftandilian
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