So that margin is not included in the rect for visibility calculations,
and padding and margin are accounted properly on them.
Differential Revision: https://phabricator.services.mozilla.com/D113853
This should be mostly straight-forward, since we have code for this
anyways for image-set() and srcset.
The only thing is that we were using floats for resolution, but since
EXIF allows you to scale each axis separately, we now need to pass an
image::Resolution instead.
The main outstanding issue is the spec comment mentioned in the previous
patch, about what happens if you have srcset/image-set and the image
density specified together. For now I've implemented what the
image-set() spec says, but this is subject to change before shipping of
course.
Differential Revision: https://phabricator.services.mozilla.com/D113265
This should be mostly straight-forward, since we have code for this
anyways for image-set() and srcset.
The only thing is that we were using floats for resolution, but since
EXIF allows you to scale each axis separately, we now need to pass an
image::Resolution instead.
The main outstanding issue is the spec comment mentioned in the previous
patch, about what happens if you have srcset/image-set and the image
density specified together. For now I've implemented what the
image-set() spec says, but this is subject to change before shipping of
course.
Differential Revision: https://phabricator.services.mozilla.com/D113265
At the moment, WebExtension menu items are special cased to allow this, by using
a click event listener which manually fires command and closes the menu.
I would like to remove the click listener, because native menus won't fire click.
Differential Revision: https://phabricator.services.mozilla.com/D111954
https://drafts.csswg.org/css-images-4/#image-set-notation has:
> [...] it also specifies the image’s natural resolution, overriding any other
> source of data that might supply a natural resolution.
Astounding that there was literally no WPT for this at all. I added three: one
for backgrounds, one for list-style-image, and one for `content`. Cursor is not
handled on this patch because that one requires a fair amount of extra work.
Differential Revision: https://phabricator.services.mozilla.com/D112474
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
At the moment, WebExtension menu items are special cased to allow this, by using
a click event listener which manually fires command and closes the menu.
I would like to remove the click listener, because native menus won't fire click.
Differential Revision: https://phabricator.services.mozilla.com/D111954
By resolving the relevant promises, instead of crashing (and if we
didn't crash we'd leave the window registered as a refresh driver
observer, which would be bad).
I wanted to reject them, since that's what we do when the page has no
pres shell, but that'd make this test fail:
https://searchfox.org/mozilla-central/rev/d8194cbbeaec11962ed67f83aea9984bf38f7c63/dom/base/test/browser_promiseDocumentFlushed.js#165-186
For this, we modify the OneShotPostRefreshObserver API to be more
generic (and rename it OneShotManagedRefreshObserver).
We fix APZ's usage of this API, which was doing something extremely
weird (returning a refcounted object in a UniquePtr). This seems like an
artifact from recent OneShotPostRefreshObserver cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D111851
Now that nsMenuPopupFrame considers itself open while the native menu is shown,
it may try to open its non-native widget if layout happens to run while the
native menu is shown.
This check prevents that.
Differential Revision: https://phabricator.services.mozilla.com/D111326
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
I introduced this assertion in bug 1702041, thinking that cancelTracking would
synchronously call menuDidClose, but that's not the case. The only reason why
this assertion isn't failing today is because we currently only call Close() on
NativeMenu in the "rollup from mousedown" scenario, where the menu has already
been closed by the OS, and we're just waiting to dispatch the MenuClosedAsync()
runnable.
Differential Revision: https://phabricator.services.mozilla.com/D110973
This shouldn't change behavior, but is the biggest cross-platform part
of the change so I'd like to get it landed sooner rather than later.
The two calls like:
GetColor(ColorID::TextSelectBackground, color);
if (color == 0x000000) {
mColorTextSelectForeground = NS_RGB(0xff, 0xff, 0xff);
} else {
mColorTextSelectForeground = NS_DONT_CHANGE_COLOR;
}
that I'm removing are just broken. They were calling the version of
GetColor the function that took a default value when the color wasn't
available, not the version of the color with the outparam.
To prevent such mistakes, add two signatures, GetColor(), returning a
Maybe<nscolor> and Color(), returning a color with a fallback.
Differential Revision: https://phabricator.services.mozilla.com/D110651
I noticed we weren't doing this when looking at bug 1701910.
We remove support for auto style outlines in trees, which is unused
(checked that thunderbird and FF trees don't use outline: auto) and for
some mathml debugging code, which seems ok.
Differential Revision: https://phabricator.services.mozilla.com/D110399
This shouldn't change behavior, but is the biggest cross-platform part
of the change so I'd like to get it landed sooner rather than later.
The two calls like:
GetColor(ColorID::TextSelectBackground, color);
if (color == 0x000000) {
mColorTextSelectForeground = NS_RGB(0xff, 0xff, 0xff);
} else {
mColorTextSelectForeground = NS_DONT_CHANGE_COLOR;
}
that I'm removing are just broken. They were calling the version of
GetColor the function that took a default value when the color wasn't
available, not the version of the color with the outparam.
To prevent such mistakes, add two signatures, GetColor(), returning a
Maybe<nscolor> and Color(), returning a color with a fallback.
Differential Revision: https://phabricator.services.mozilla.com/D110651
I noticed we weren't doing this when looking at bug 1701910.
We remove support for auto style outlines in trees, which is unused
(checked that thunderbird and FF trees don't use outline: auto) and for
some mathml debugging code, which seems ok.
Differential Revision: https://phabricator.services.mozilla.com/D110399
I noticed we weren't doing this when looking at bug 1701910.
We remove support for auto style outlines in trees, which is unused
(checked that thunderbird and FF trees don't use outline: auto) and for
some mathml debugging code, which seems ok.
Differential Revision: https://phabricator.services.mozilla.com/D110399
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 copied from the nsMenuPopupFrame::ShowPopup just a few lines below.
The native menu consumes mouseup events so we need to clear :active and capturing content just before opening the menu.
Differential Revision: https://phabricator.services.mozilla.com/D109672
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
This patch doesn't change behavior; GetCrossDocParentFrameInProcess() is just a
wrapper for GetCrossDocParentFrame(), which is what we were calling before.
The "InProcess" version of this API (which we're migrating to in this patch) is
used to annotate GetCrossDocParentFrame() callsites that have been vetted as
being OK with the fact that this API returns null at the boundary of a
cross-origin iframe, if fission is enabled.
In this patch, the one call that I'm migrating is inside of XUL code
(specifically for the rendering of XUL trees); and we only expect to be
rendering XUL in a single process: Firefox's parent process. So this code
should be entirely OK with the fact that this API doesn't cross process
boundaries.
Differential Revision: https://phabricator.services.mozilla.com/D108708
Using `dlsym` for `gdk_wayland_display_get_type` is a cleaner solution
to bug 1696319, allowing running with a GTK that lacks the Wayland
backend.
Also adds a symmetric implementation for `gdk_x11_display_get_type`,
which should help running without X11.
Differential Revision: https://phabricator.services.mozilla.com/D107406
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
Using `dlsym` for `gdk_wayland_display_get_type` is a cleaner solution
to bug 1696319, allowing running with a GTK that lacks the Wayland
backend.
Also adds a symmetric implementation for `gdk_x11_display_get_type`,
which should help running without X11.
Differential Revision: https://phabricator.services.mozilla.com/D107406
(Almost?) all other scrollbar performed scrolling goes through apz already (this effort was called "desktop_zooming_scrollbars").
This one mode was missed. It uses a repeating timer and setting the curpos attribute to trigger scrolling.
Unfortunately xul trees use this path as well, so we have to keep the old path around for them.
This makes one notable change in behaviour. Both before and after this patch single clicks on scrollbar buttons pass ENABLE_SNAP to the scroll from when they request scrolling (in nsScrollbarButtonFrame::HandleButtonPress). However for repeat scrolling when clicking and holding (which is handled by nsScrollbarFrame::MoveToNewPosition), before this patch the scrolling would not use ENABLE_SNAP. This is not super clear because MoveToNewPosition sets the curpos attributes, and then ScrollFrameHelper::CurPosAttributeChanged( would get called in response to that, and it would call ScrollToWithOrigin to the do scrolling, and it does not specify the snap mode, but the default is DISABLE_SNAP. This patch changes that so that we explicitly pass ENABLE_SNAP in MoveToNewPosition. It seems that this was likely overlooked (not hard to do when it's not clear like this) when adding snapping support. It makes sense to handle snapping the same way for single clicks and clicking and holding. If this turns out to be the wrong idea we can easily change it back.
Needs a test.
Differential Revision: https://phabricator.services.mozilla.com/D105288
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
For minimizing the previous patch changes, `scale`'s default value for
`screenX/Y` is treated as 1.0. It means that `screenX/Y` are device
pixels by default, but `offsetX/Y` are in CSS pixels by default. This
difference may make developers confused. Therefore, we should align the
default unit of them to `screenPixelsPerCSSPixel`. I.e., their default
unit becomes CSS pixels.
Differential Revision: https://phabricator.services.mozilla.com/D105929
For making the test framework/API change easier, such raw API shouldn't be
used directly. Therefore, this patch makes tests using it directly stop
using it and use `synthesizeNativeMouseEvent` instead.
However, this patch does not fix `browser_touch_event_iframes.js` because
it accesses the API from `ContentTask`. So, `EventUtils.js` isn't available
without larger change.
Note that this patch disables `test_bug596600.xhtml` because as I commented
in it, it's completely broken. It depends on the race of next native event
loop and `waitForTick`, and this patch changes the result of the race.
Differential Revision: https://phabricator.services.mozilla.com/D105765
Currently, it takes a raw native message value, but it makes JS content too
complicated. And on Linux, it cannot synthesize non-primary button events
because GDK has only button press and release messages which dont' include
mouse button information.
For solving these problems, this patch creates a new abstract native message
as `nsIWidget::NativeMouseMessage` and makes each widget converts it to
a platform native message.
Additionally, this patch adds an argument to make it possible its callers
to specify pressing or releasing mouse button with a DOM mouse button value.
Note that the following patch adds new argument to
`synthesizeNativeEventMouse*` for mochitests and which will be tested by
new tests.
Differential Revision: https://phabricator.services.mozilla.com/D105763
In these days, API should take an `Object` instead of multiple arguments
since the callers look like using "named" arguments and this allows to
add new optional arguments with changing not all callers.
This patch also changes similar API for APZ aware tests for keeping
consistent style for their users.
Differential Revision: https://phabricator.services.mozilla.com/D105755
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
This patch is the result of auditing all places that look at the presence or absence of a display port to handle minimal display ports (HasDisplayPort, GetDisplayPort, etc).
Broadly speaking the places were in two categories:
1) things related to painting, that want to consider minimal display ports as display ports for purposes of things like sending over metadata and separating out layers.
2) things that care about async scrolling, and so actually want to have a properly sized display port.
Type 1) were not changed by this patch. Type 2) were changed to consider minimal display ports as not display ports.
Again, we are aiming to leave behaviour unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D103856
There's no reason we should need an scrollbar box to query the size of a
scrollbar. I plan to use this in the following patch to make the size of a
resizer not vary depending on whether the container has scrollbars or not,
which is what ultimately causes the reftest failure.
Differential Revision: https://phabricator.services.mozilla.com/D103302
This patch adds the struct as a parameter to various functions.
The struct is cached in ReflowInput so that we don't need to pass it
down to the internal method where nsIFrame::ComputeSize() is called.
In the subsequent patches, we'll use it to revise the implementation of
flex container's flex base size resolution, and size overrides.
Differential Revision: https://phabricator.services.mozilla.com/D101793
This patch adds the struct as a parameter to various functions.
The struct is cached in ReflowInput so that we don't need to pass it
down to the internal method where nsIFrame::ComputeSize() is called.
In the subsequent patches, we'll use it to revise the implementation of
flex container's flex base size resolution, and size overrides.
Differential Revision: https://phabricator.services.mozilla.com/D101793
This patch adds the struct as a parameter to various functions.
The struct is cached in ReflowInput so that we don't need to pass it
down to the internal method where nsIFrame::ComputeSize() is called.
In the subsequent patches, we'll use it to revise the implementation of
flex container's flex base size resolution, and size overrides.
Differential Revision: https://phabricator.services.mozilla.com/D101793
OneShotPostRefreshObserver works as the caller registers it, and
let it deletes itself via the DidRefresh method. The issue is that
DidRefresh is not guaranteed to run, and it'll leak PresShell
if it doesn't run.
This patch allows nsPresContext to store and release the last
registered OneShotPostRefreshObserver, and converted the existing
usage of OneShotPostRefreshObserver to use that. So instead of asking
OneShotPostRefreshObserver to delete itself, we now ask nsPresContext
to release it.
Differential Revision: https://phabricator.services.mozilla.com/D99939
This allows supporting image-set(), etc, and simplifies the bullet frame
code significantly, too thanks to two changes:
* Instead of manually managing the image request, use the CSS image
loader, with the `REQUEST_REQUIRES_REFLOW` flag, to handle image
loads correctly. This didn't exist when this code was initially
implemented, but we can nicely use it now.
* Instead of re-implementing another WebRender command-builder thing,
we can just reuse the nsImageRenderer code.
Differential Revision: https://phabricator.services.mozilla.com/D100774
This allows supporting image-set(), etc, and simplifies the bullet frame
code significantly, too thanks to two changes:
* Instead of manually managing the image request, use the CSS image
loader, with the `REQUEST_REQUIRES_REFLOW` flag, to handle image
loads correctly. This didn't exist when this code was initially
implemented, but we can nicely use it now.
* Instead of re-implementing another WebRender command-builder thing,
we can just reuse the nsImageRenderer code.
Differential Revision: https://phabricator.services.mozilla.com/D100774
This lifts a bunch of string conversions higher up the stack, but allows
us to make the servo code use utf-8 unconditionally, and seemed faster
in my benchmarking (see comment 0).
It should also make a bunch of attribute setters faster too (like
setting .cssText), now that we use UTF8String for them (we couldn't
because we couldn't specify different string types for the getter and
setters).
Differential Revision: https://phabricator.services.mozilla.com/D99590
This doesn't hold with fractional scale values. Right now GTK truncates
the scale factor, Windows rounds, and non-native theme rounds as well.
With this native theme will propagate correctly the floating point
values.
I tried to not change behavior meaningfully in any of the other themes,
mostly to avoid risk. GTK and Windows can be trivially tweaked to
support fractional scale factors properly if we wanted to, but seems
better to not do that as part of this patch.
Depends on D98099
Differential Revision: https://phabricator.services.mozilla.com/D98100
Collapsible splitters with reordered boxes are broken even before
bug 1411372. The patch in this bug progresses them but I have no
intention to fully fix them.
Test that the splitter moves in the right direction too.
Differential Revision: https://phabricator.services.mozilla.com/D97871
`keyup` event of `Alt` key should be fired in content process even if it'll
activate the menubar, and it should be cancelable as same as before enabling
e10s.
Unfortunately, the new test is complicated even they test simple things.
The reason is, this test requires the window running it is the active window.
However, the window may become inactive on Linux, therefore, this test
needs to manage window state by itself.
And another reason is, after inactivating the menubar, somebody keeps
consuming keyboard events in chrome. Although, popups shouldn't be
opened by this test, but waiting all popups hidden makes the remaining
intermittent failure gone. Therefore, this patch waits all popups become
hidden after inactivating the menubar and before new test.
Differential Revision: https://phabricator.services.mozilla.com/D95984
This removes one const_cast but also adds two new ones. I think
the new ones are reasonable - conceptually the function does not
modify the input, so the input should be const. If that input
is returned as the output then we need to strip the const because
the return value shouldn't be const (because the caller should be
free to modify it if desired).
Depends on D97622
Differential Revision: https://phabricator.services.mozilla.com/D97623
This patch is generated via the rename functionality in my editor; add
`mozilla::` prefix to `OverflowAreas` in headers; and remove the
`OverflowType` alias added in Part 1.
Differential Revision: https://phabricator.services.mozilla.com/D97235
`keyup` event of `Alt` key should be fired in content process even if it'll
activate the menubar, and it should be cancelable as same as before enabling
e10s.
Unfortunately, the new test is complicated even they test simple things.
The reason is, this test requires the window running it is the active window.
However, the window may become inactive on Linux, therefore, this test
needs to manage window state by itself.
And another reason is, after inactivating the menubar, somebody keeps
consuming keyboard events in chrome. Although, popups shouldn't be
opened by this test, but waiting all popups hidden makes the remaining
intermittent failure gone. Therefore, this patch waits all popups become
hidden after inactivating the menubar and before new test.
Differential Revision: https://phabricator.services.mozilla.com/D95984
Whether scrollbar buttons are shown is currently determined by
LookAndFeel values, and these are exposed through system metric media
features. LookAndFeel values are process-wide, but which theme is in
use is document-specific. (It can be the platform's native theme or the
native basic theme, depending on Document::ShouldAvoidNativeTheme.) So
if nsNativeBasicTheme on Linux needs to not support scrollbar buttons,
we can't do this by forcing the LookAndFeel values to be false.
So instead, we skip creating the native anonymous content for the
scrollbar buttons when the non-native theme is in use on Linux. There's
no need to support dynamic changes, since whether the non-native theme
is in use for a given document never changes.
Differential Revision: https://phabricator.services.mozilla.com/D96345
Instead, sort stuff using CSSOrderAwareFrameIterator. The current
sorting is broken in presence of dynamic insertions, consider the
following <Child(order)> combination in the DOM:
<A(1000)> <B(0)>
That'd look like:
<B(0)> <A(1000)>
On the frame tree. However when appending a child before B so that the
DOM looks like:
<A(1000)> <C(0)> <B(0)>
The frame constructor will properly insert after A, and the reordering,
which is stable, will end up with:
<B(0)> <C(0)> <A(1000)>
Which is the wrong frame tree order.
We only use -moz-box-ordinal-group in regular sprocket layout, so just
handle it there rather than everywhere. Similarly, we only rely on it
for in-flow stuff, so remove the test for that added in bug 877890 (flex
changed behavior afterwards, interestingly enough).
Differential Revision: https://phabricator.services.mozilla.com/D94790
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
For future archaeologist: `eReflowReason` used in `nsAdaptorPrintReason`
was originally defined in nsHTMLReflowState.h (today's ReflowInput.h),
and was removed in Bug 300030
31f1898810
Differential Revision: https://phabricator.services.mozilla.com/D94042
When the pref size changes, we set the bounds of the popup to the pref
size, which is the size of all the contents, usually. It's
SetPopupPosition what takes care of flipping / constraining / etc, so
make sure that happens.
Differential Revision: https://phabricator.services.mozilla.com/D93226
In particular, for "continuous" scrolling methods - autoscroll, scrollbar
dragging, trackpad panning, and touch panning, this patch records the *start*
of the gesture rather than on every frame or input event *during* the gesture.
This conceptually changes the metric from being implementation-centric to being
more user-centric, in that each conceptual "user gesture" counts towards one
SCROLL_INPUT_METHOD record. This is more useful for the purposes of recording
user intent with respect to scroll input methods for experiments.
Depends on D92995
Differential Revision: https://phabricator.services.mozilla.com/D92996
This is mostly a revert of the patch in bug 1425686 that removed the old
probe, but rebased to new code locations and clang-formatted. The histogram
entry is also updated with new bug numbers and fields.
The next patch will refine some of these telemetry recording points; the patch
is split into two for easier reviewing as this part is basically what landed
originally.
Differential Revision: https://phabricator.services.mozilla.com/D92995
The tooltip width can be real number in the hidpi display setup
or when the font scaling is used. In this case the nsWindow GTK
implementation will cut out the non integer part which leads to
narrowing the tooltip and later overflowing the text which
is in the tooltip to next line. This workaround patch adds
a one pixel to the tooltip frame when the tooltip has real number
width or height.
Differential Revision: https://phabricator.services.mozilla.com/D92620
We don't need to flush before dispatching the event because we know that
if the values we cared about changed, then we'd get another event.
Differential Revision: https://phabricator.services.mozilla.com/D92444
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
If the position expected position of popup is not changed by the GTK (it popup fit into the screen)
we don't have to update position of nsMenuPopupFrame in Gecko view. We sent the anchor position
instead of expected popup position to the NativeMoveResizeWaylandPopup which triggered the view changes.
Differential Revision: https://phabricator.services.mozilla.com/D92043
Along with a dependent struct DirectDrawInfo.
This allows nsImageRenderer.h and CanvasRenderingContext2D.h to
avoid including nsLayoutUtils.h.
For nsImageRenderer.h in particular, a forward declaration is
not sufficient as nsImageRenderer stores SurfaceFromElementResult
by value.
A couple of method definitions elsewhere are moved out of line
to keep things compiling without including nsLayoutUtils.h in
additional headers.
Differential Revision: https://phabricator.services.mozilla.com/D91684
nsContainerFrame.h was only using the enum nsLayoutUtils::IntrinsicISizeType,
which this patch moves to LayoutConstants.h instead.
Depends on D91505
Differential Revision: https://phabricator.services.mozilla.com/D91506
The only thing in nsIFrame.h that was using it was the implementation
of a templated method, which could be moved to nsIFrameInlines.h.
Depends on D91504
Differential Revision: https://phabricator.services.mozilla.com/D91505
In the next part, I'm going to use ComputeSizeFlags as the arguments in
some ReflowInput's methods. Because nsIFrame.h includes ReflowInput.h,
to solve the circular dependency, ComputeSizeFlags needs to be moved to
somewhere else.
Also, revise the document for ComputeSizeFlag. The rest of the patch is
just dropping `nsIFrame::` and adding `mozilla::` as needed.
This change shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D89542
I had written this on one of my attempts to fix the missing text on
reddit when printing, but I think it's worth landing anyways not only
because it's slightly cleaner, but because it avoids the virtual call
and style checks when we're not printing.
This should be an idempotent change.
Differential Revision: https://phabricator.services.mozilla.com/D89171
The editor modules does QI too many times when it sets or removes some style
with `execCommand` or XPCOM API. Therefore, there should be an API to
retrieve `nsStyledElement` pointer from `nsINode*`.
Differential Revision: https://phabricator.services.mozilla.com/D87990
Also: adjust include paths to be consistent for usages of various SVG headers,
and remove unused SVG includes (mostly for "utils" classes),
and drop stray "ns" from already-renamed SVG classes in various code comments.
Differential Revision: https://phabricator.services.mozilla.com/D83140
This is a straightforward conversion except that
`NS_SUBTREE_DIRTY(this)` can be written terser as `IsSubtreeDirty()`.
Differential Revision: https://phabricator.services.mozilla.com/D82811
Apply the fix for bug 1592416 to submenus.
This adds the NSWindowCollectionBehaviorMoveToActiveSpace behavior to
submenu popups so that they override the "Assign To" space setting and display
on the active space. And, when mutiple displays are in use, recreates the
submenu widget each time it is displayed.
Differential Revision: https://phabricator.services.mozilla.com/D81812
We did not pass FLAG_HIGH_QUALITY_SCALING down to the document used to
rasterize the SVG to a surface, resulting in embedded raster images to
not use high quality downscaling.
Differential Revision: https://phabricator.services.mozilla.com/D56422
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