Remove the follow-firefox-theme pref as now that's default everywhere,
and document better the behavior of the color-scheme property by
reworking and commenting the logic on it a bit.
Differential Revision: https://phabricator.services.mozilla.com/D128610
This was pre-existing but caught by some scrollbar-width tests. A
test-case that reproduces on current nightly:
data:text/html,<html style="overflow: scroll; scrollbar-color: red red; scrollbar-width: thin">
Toggling the `scrollbar-width` declaration in devtools doesn't change
the effective scrollbar width. Ensure we correctly reflow the scrollbars
in this case.
Differential Revision: https://phabricator.services.mozilla.com/D128515
This stuff is now a no-op because the RequestContentRepaint message has a
higher priority than vsync.
Depends on D127033
Differential Revision: https://phabricator.services.mozilla.com/D127593
We have JS listeners that are expected to run once the LookAndFeel
caches have been cleared and such, so split the look-and-feel-changed
notification into an internal and external notification.
Differential Revision: https://phabricator.services.mozilla.com/D128097
We make it work on macOS by setting pointer-events: none + opacity: 0 rather
than visibility: hidden, and tweaking the caching setup to be Android-like.
Now that the scrollbars sheet is the same across platforms, move it to where
the rest of the UA sheets are. This way we guarantee that the RDM vs. Android
difference is less (just the ifdef at the top of the sheet).
Depends on D128084
Differential Revision: https://phabricator.services.mozilla.com/D128085
`nsTextFragment` is a storage of data node and DOM offset is `uint32_t`, but
some methods of `nsTextFragment` takes `int32_t` for the offset/length in
its text. Therefore, callers need to cast from `uint32_t` to `int32_t` if
the offset value is offset in a DOM node. Therefore, all methods of it should
take `uint32_t` values as offset/length in its text.
Differential Revision: https://phabricator.services.mozilla.com/D127923
There are a lot of check of `Document`'s editable state **with** comments. This
means that it's unclear for developers that only `Document` node is editable in
design mode.
Additionally, there are some points which use composed document rather than
uncomposed document even though the raw API uses uncomposed document. Comparing
with the other browsers, checking uncomposed document is compatible behavior,
i.e., nodes in shadow trees are not editable unless `contenteditable`.
Therefore, `nsINode` should have a method to check whether it's in design mode
or not.
Note that it may be called with a node in UA widget. Therefore, this patch
adds new checks if it's in UA widget subtree or native anonymous subtree,
checking whether it's in design mode with its host.
Differential Revision: https://phabricator.services.mozilla.com/D126764
Bug 1696718 landed a fix to propagate the position change from layout.
However that's not correct, because the widget isn't resized until
nsView::ProcessPendingUpdatesForView is resized (and even that in some
platforms it might be async).
So the right place to propagate the position change is in
nsXULPopupManager (which we call into from the view system which listens
itself to the widget).
Let's try to enable the test for that bug everywhere with this fixed.
Differential Revision: https://phabricator.services.mozilla.com/D127801
With the old layers backend we had low precision buffer code controlled via the pref layers.low-precision-buffer that was used on android. We would expand the displayport by 4x and then paint it as 1/4 the resolution, and then we would have a critical displayport without the 4x multipler that we would paint at the real resolution. The code to do the painting at the lower resolution was in the layers backend and has since been removed. (This is okay because webrender doesn't rasterize all of the content in the displayport.) So the critical displayport or displayport are no longer treated differently anywhere. Except a few pieces of code that should be fixed/changed/removed. This patch being one of them.
GetHighResolutionDisplayPort would return the displayport without the multipler in all situations (pref on or off).
In DisplayPortUtils we are checking the displayport rect before/after setting new displayport margins to see if it changes to determine if we need to invalidate. Since the critical displayport isn't used for anything, the regular displayport is the correct thing to use here.
In nsGfxScrollFrame we are doing a similar thing, except checking that the displayport doesn't change after a scroll.
In nsDisplayListBuilder::OutOfFlowDisplayData::ComputeVisibleRectForFrame it's also the correct thing, as we want to include the same rect for fixed content as we do for non-fixed content. But this is an significant expansion of the dirty rect of fixed content and the code history has fixes related to drawing too much of fixed content and OOMing so a little more scrutiny is reasonable. However if there was a problem with OOM, since this is the same rect we use for non-fixed content we would have OOM problems with regular content, so this should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D127344
This else should only get hit if we can't get the docshell or content viewer from the prescontext, which should only be unusual setting up or tearing down timeframes, so it doesn't matter too much.
Differential Revision: https://phabricator.services.mozilla.com/D126659
In bug 1731929 we added this value, here we give it the value we want for child processes. I think the code comments should explain it.
Differential Revision: https://phabricator.services.mozilla.com/D126629
Noemi Erli
Evgenia Kotovich
Mats Palmgren
Cristian Tuns
Emilio Cobos Álvarez
Alexandru Michis
Butkovits Atila
Hiroyuki Ikezoe
Timothy Nikkel
Masayuki Nakano
Marian-Vasile Laza
Jeff Muizelaar
Jens Stutte
Sandor Molnar
Morgan Reschenberg