This can run script, and as such shouldn't run from a container query
update. Instead, let's move the check to DidDoReflow, which deals with
that appropriately already.
I don't know of an easy / reliable way to reproduce this, since paint
unsuppression is very timing-dependent.
While at it, remove the long reflow telemetry check for
GetRootElement(). This comes from a time where we used the root
element's namespace to determine which telemetry counter to use.
Differential Revision: https://phabricator.services.mozilla.com/D197477
When the line scroll amount is larger than that of the rectangle to
scroll into view, do not use the line size to determine if we should
scroll.
Depends on D192869
Differential Revision: https://phabricator.services.mozilla.com/D192870
-moz-window-shadow is a chrome-only property (not exposed to the web),
and chrome stylesheets only use the none value to disable the default
behavior.
Split the style property (default/none) from the actual widget behavior.
This is useful because I want to add a distinction between
natively-styled menupopups and other panels in the following commit.
While at it rename default to "auto" which is a more common name in CSS
for something like this.
We have no use case for removing the shadow of a top-level window, so
remove it to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D197454
Currently, the method ignores synthesized `eMouseMove` events coming from the
parent process if
* the last mouse location was updated by a synthesized mouse event for tests
* the event comes from parent process
* the event is not marked as synthesized for tests
However, `eMouseExitFromWidget` is also handled as a synthesized `eMouseMove` [1].
Therefore, the method needs to ignore this event too in the same conditions.
Additionally, `eMouseEnterIntoWidget` may cause updating the `:hover` state
under the event position which may be different from the last cursor position
in the content process [2]. Therefore, the method needs to ignore this too.
On the other hand, if the event is caused by a test API synthesizing mouse
events, e.g., when `test.events.async.enabled` is set to `true`, the running
test must expect the events. Therefore, these events need to be marked as
synthesized for tests correctly. Therefore, this patch updates the
initializers of the events.
1. https://searchfox.org/mozilla-central/rev/78a2c17cc80680a5a82446e4ce7c45a73b935383/dom/events/EventStateManager.cpp#773,794-796,800-801
2. https://searchfox.org/mozilla-central/rev/78a2c17cc80680a5a82446e4ce7c45a73b935383/dom/events/EventStateManager.cpp#4063,4068
Differential Revision: https://phabricator.services.mozilla.com/D195638
Implement experimental transparent-on-hover behavior for the
picture-in-picture video player. This makes the popup player less of
a nuisance on smaller displays.
Tested on macOS, but should also work on Windows with small tweaks.
The behavior is hidden behind a pref:
media.videocontrols.picture-in-picture.seethrough-mode.enabled
Differential Revision: https://phabricator.services.mozilla.com/D193993
When the line scroll amount is larger than that of the rectangle to
scroll into view, do not use the line size to determine if we should
scroll.
Differential Revision: https://phabricator.services.mozilla.com/D192870
Extend the per-frame-class bit we have to devirtualize IsLeaf to also
devirtualize IsFrameOfType. That is, move this data to FrameClasses.py.
This was done by going through all the frame classes, trying to preserve
behavior.
The only quirky thing is that I had to add two more trivial frame
classes, `nsAudioFrame` for audio elements, and
`nsFloatingFirstLetterFrame`. That's because these frame classes were
returning different answers at runtime, but they do this only on
conditions that trigger frame reconstruction (floating, and being an
audio element, respectively).
Differential Revision: https://phabricator.services.mozilla.com/D194703
This fixes the flash mentioned in bug 1858405 comment 6.
I don't think this is realistically testable tho, since this is only for
non-content-accessible, temporary documents (if you load about:blank
directly that's not an initial doc).
Differential Revision: https://phabricator.services.mozilla.com/D194246
This patch removes the old docshell timeline and timeline markers codebase and replaces them with equivalent Gecko profiler marker. This patch also fixes Bug 1834143, which is a subset of 1421651.
Differential Revision: https://phabricator.services.mozilla.com/D184217
This patch removes the old docshell timeline and timeline markers codebase and replaces them with equivalent Gecko profiler marker. This patch also fixes Bug 1834143, which is a subset of 1421651.
Differential Revision: https://phabricator.services.mozilla.com/D184217
These days, after bug 1853323, about:PreferenceStyleSheet is basically
just an empty sheet for most users. For the ones that isn't, it's either
slightly or completely broken (see below).
If we were to implement this today, we'd do it with privileged env()
variables or media queries, and add a bunch of tests for different
combinations, but I don't think it's worth the effort:
* There's no UI for any of these prefs.
* There are no tests for any of these prefs.
* browser.display.focus_ring_or_anything is not great, it's better
replaced by browser.display.show_focus_rings, which actually makes
the :focus-visible pseudo-class work. Otherwise the native controls
may show no rings even though this pref is set.
* for browser.display.focus_ring_style = 0, the color used
(-moz-mac-focusring) is not implemented in any non-macOS platform.
* The ::-moz-focus-inner rules are completely useless nowadays, because
::-moz-focus-inner only works on the windows native theme (which
isn't used on content).
* The focus colors are not color-scheme aware.
So given those, and that if you want the specific current behavior,
these are trivially implementable as a web extension (by using a user
stylesheet), I think we should just remove this code altogether.
Differential Revision: https://phabricator.services.mozilla.com/D190464
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
These days it's just a very thin wrapper over an nsTArray of
ResizeObservers. We also schedule notifications for resize observations
for the whole BrowsingContext tree at once, so there's no point on
individually keep track of them.
Differential Revision: https://phabricator.services.mozilla.com/D190113
If an event will not be handled by accessible caret, do not use the
event reference point that may have been modified by event retargetting.
Restore the original reference point.
Depends on D185327
Differential Revision: https://phabricator.services.mozilla.com/D187896
This massive hack shouldn't be needed after the previous patch, and
throttling of in-process and out-of-process should be consistent now.
Differential Revision: https://phabricator.services.mozilla.com/D185809
