The caret position is in the DOM, and sometimes can get out of sync.
While that is an issue, it's not new: The code before the regressing bug
papered over it on a pre-pass before entering DL building.
Instead, deal with it using MarkFramesForDisplay (just like we mark the
caret frame itself, which has the same issue), and invalidate the old
frame more precisely by tracking it in nsCaret directly.
Also, add missing invalidation in PresShell::SetCaret, where the caret
might change and the old caret might not be invalidated properly.
Differential Revision: https://phabricator.services.mozilla.com/D205369
Firefox never uses this. TB could use the same approach Firefox uses,
but for now on macOS the sheets become regular modal dialogs, which is
the same as on Windows and Linux.
See bug 1755330 and bug 1737489 for more context.
Differential Revision: https://phabricator.services.mozilla.com/D204209
As far as investigating the behavior of the other browsers, touch events are
dispatched the same target as the preceding `pointerdown` even after the target
is removed from the DOM tree. However, the following pointer events are
dispatched on the target as usual (i.e., the element under the pointer except
when the pointer is captured). However, our code stops handling touch events
if the preceding `pointerdown` removes the target and not dispatching
`touchstart` causes not dispatching the following touch events so that no
`click` event is fired.
This patch makes the touch event dispatching path work without frame and
keep handling even with an orphan event target.
Differential Revision: https://phabricator.services.mozilla.com/D202811
The reason of the bug is, no `mouseup` event is fired after the `pointerup`
event listener removed the target. Therefore, `nsIFrame::HandleRelease()` does
not run and nobody cleans up the drag state of the `nsFrameSelection`.
This is caused by that `PresShell::EventHandler::DispatchPrecedingPointerEvent()`
updates only event target frame of the following mouse event target if the
pointer event target was removed from the tree, however, the frame may not be
ready. In this case, `PresShell::GetCurrentContent()` will clear both current
event target content and frame because its composed document (`nullptr`) never
matches with the document for the `PresShell`. Therefore, it needs to update
the target too.
This patch makes all developers won't create similar bugs, this encapsulate
`EventTargetData::mContent` and `EventTargetData::mFrame` to make their setters
clean up or automatically check the relation.
Differential Revision: https://phabricator.services.mozilla.com/D201053
`mouse_boundary_events_after_removing_last_over_element.html` expects that
a `mouseover` should be fired between `click` and `mousemove`, but it's
dispatched by a synthetic mouse move event caused by removing the click target.
The fix of bug 1864654 tried to fix this kind of issues, but it does not flush
pending event at `eMouseMove`. Therefore, the synthetic mouse move may not be
handled before handling `eMouseMove` which is caused by `pointerMove()` in the
test.
I guess that we need to make it flush before all events which are directly
caused by a user input. However, I don't want to do it for now because of
the risk.
Depends on D199607
Differential Revision: https://phabricator.services.mozilla.com/D199694
`inert-iframe-hittest.html` expects that `:hover` state should be updated
immediately after a pointer down. The state is updated by
`EventStateManager::NotifyMouseOver` [1] when we received a real or synthetic
`eMouseMove`. Therefore, the hover state may have not set yet if no refresh
occurs between the pointer down and checking the result.
Additionally, some WPT for UI Events and Pointer Events expect that `mouseover`
or `mouseout` should be fired before `mouseup`/`pointerup` if a preceding
`mousedown` or `pointerdown` event listener removes the target. So, this
patch may fix intermittent failures of them if there are.
Therefore, we should flush pending synthetic `mousemove` event for keeping the
event order as same as they happen. However, simply flushing it causes
unexpected pointer capture state change because
`PointerEventHandler::ProcessPointerCaptureForMouse` handles synthetic
`mousemove` but it should not cause pointer boundary events at the moment (the
pointer boundary events should be fired when the pointer is actually moved, note
that this is different rule from the rules of mouse boundary events).
Therefore, this patch changes
`PointerEventHandler::ShouldGeneratePointerEventFromMouse`.
However, this blocks `lostpointercatpure` event when the capturing content has
already been removed from the DOM tree. The path is,
`EventHandler::HandleEventWithPointerCapturingContentWithoutItsFrame` stops
dispatching `pointerup` nor `pointercancel` in this case, but
`EventStateManager::PostHandleEvent` is the only handler of implicit pointer
capture release. Therefore, we need to make it dispatch lostpointercatpure`
event if the canceling event caused `ePointerUp` or `ePointerCancel`.
Finally, this patch fixes a bug of `browser_ext_browserAction_popup_preload.js`.
It tests the pre-loading which starts when `mouseover` before `mousedown` on a
widget. However, it does not correctly emulate the user input.
* Synthesizing only `mouseover` does not update the internal pointer info and
does not cause dispatching related events.
* Synthesizing `mousedown` without `mousemove` cause `mouseover` before
`mouseup` because at dispatching `mousedown`, `PresShell` stores the cursor [2]
and the mouse boundary events will be dispatched before `mouseup`.
`ext-browserAction.js` assumes the events are fired as this order,
`mouseover` -> `mousedown` -> `mouseup`, but this would not work if the
preceding `mousemove` of `mousedown` is not correctly fired. I'm not sure
whether `mousemove` is always fired before `mousedown` on any environments,
but it should be rare and it affects only this kind of tricky code. For now,
fixing this in the test side must be enough.
1. https://searchfox.org/mozilla-central/rev/9a5bf21ea2dd04946734658f67f83f62ca76b0fa/dom/events/EventStateManager.cpp#4874,4913-4914
2. https://searchfox.org/mozilla-central/rev/9a5bf21ea2dd04946734658f67f83f62ca76b0fa/layout/base/PresShell.cpp#6756
Differential Revision: https://phabricator.services.mozilla.com/D193870
Right now, we reconstruct frames in response to a change in the CSS
`contain` property or `content-visibility`. This patch tries to optimize
this a bit:
1. Updates involving style containment change continue to force a
reconstruction, due to the need to handle counters/quotes.
2. Updates involving paint/layout containment change only force a
reconstruction if it's needed to handle absolutely/fixed
positioned descendants or floats (for this one, see also bug 1874826).
3. Other containment changes will only force a reflow and repaint.
Per the CSS contain spec, layout, style and paint containments are
enabled for `content-visibility: hidden` and `content-visibility: auto`.
As a consequence, changing `content-visibility` between `hidden` and
`auto` values no longer requires reconstruction. Changing between these
values and `visible` may need a reconstruction although authors may
generally avoid that in practice by forcing `style` containment.
Differential Revision: https://phabricator.services.mozilla.com/D197043
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
In some edge cases, we may start handling user input events that
are not supposed to be handled by the current document.
This patch introduces some delay to handle user input events.
Differential Revision: https://phabricator.services.mozilla.com/D180976
In some edge cases, we may start handling user input events that
are not supposed to be handled by the current document.
This patch introduces some delay to handle user input events.
Differential Revision: https://phabricator.services.mozilla.com/D180976
In some edge cases, we may start handling user input events that
are not supposed to be handled by the current document.
This patch introduces some delay to handle user input events.
Differential Revision: https://phabricator.services.mozilla.com/D180976
The subdocument call when there's no root frame is silly, because we
won't find a canvas frame and we'll end up with transparent.
This needs to tweak the canvas frame construction code to make canvas
anon content show up on the "top" canvas, not on the page content
canvas.
This can be simplified now, because the reason we had to build canvas
anon content before processing kids of the root frame (bug 1558352) no
longer applies since I made popups regular out-of-flow elements
(bug 1799343).
Differential Revision: https://phabricator.services.mozilla.com/D179461
We've already known that `WidgetQueryContentEvent` is dispatched at initializing
a popup menu on macOS (bug 1530188). Therefore, I made the dispatcher under
`widget/cocoa` set `WidgetQueryContentEvent::mNeedLayoutFlush` to `false` to
avoid to flush pending things in `ContentEventHandler`, but
`PresShell::EventHandler` does it.
Differential Revision: https://phabricator.services.mozilla.com/D185264
Subtle things:
* We now have shadow trees in NAC, inception! Only a couple lines of
code in the style system had to be changed to match :host rules and
so properly.
* Had to make highlighters.css contentaccessible, because otherwise we
can't load it from the shadow tree. I don't think it's a big deal.
* I removed some of the code from highlighters.css that claimed that
stuff inherited from the html element. That's just no longer true.
* Had to switch from `setAttribute("style", ...)` to `.style = ...;`.
This is needed because CSSOM from chrome code bypasses CSP (as
AnonymousContent did), but setAttribute() doesn't, see bug 1424474.
Differential Revision: https://phabricator.services.mozilla.com/D173998
Subtle things:
* We now have shadow trees in NAC, inception! Only a couple lines of
code in the style system had to be changed to match :host rules and
so properly.
* Had to make highlighters.css contentaccessible, because otherwise we
can't load it from the shadow tree. I don't think it's a big deal.
* I removed some of the code from highlighters.css that claimed that
stuff inherited from the html element. That's just no longer true.
* Had to switch from `setAttribute("style", ...)` to `.style = ...;`.
This is needed because CSSOM from chrome code bypasses CSP (as
AnonymousContent did), but setAttribute() doesn't, see bug 1424474.
Differential Revision: https://phabricator.services.mozilla.com/D173998
Subtle things:
* We now have shadow trees in NAC, inception! Only a couple lines of
code in the style system had to be changed to match :host rules and
so properly.
* Had to make highlighters.css contentaccessible, because otherwise we
can't load it from the shadow tree. I don't think it's a big deal.
* I removed some of the code from highlighters.css that claimed that
stuff inherited from the html element. That's just no longer true.
* Had to switch from `setAttribute("style", ...)` to `.style = ...;`.
This is needed because CSSOM from chrome code bypasses CSP (as
AnonymousContent did), but setAttribute() doesn't, see bug 1424474.
Differential Revision: https://phabricator.services.mozilla.com/D173998
That's how we do it for all other platforms. Do this rather than via a
custom mostly-untested pref, which allows us to simplify text zoom
handling.
Differential Revision: https://phabricator.services.mozilla.com/D177062
Much like in bug 1620575. The front-end works with sizing in int CSS
pixels, so size to that so that there isn't a mismatch between our size
and the window size.
Differential Revision: https://phabricator.services.mozilla.com/D176359
Now that we've removed nsXULScrollFrame, ScrollFrameHelper can be
subsumed under nsHTMLScrollFrame.
I want to do this before making scrollbars non-XUL.
Renaming to mozilla::ScrollFrame is left for a follow-up bug.
Differential Revision: https://phabricator.services.mozilla.com/D173063
The only XUL frames that remain are either scrollbars, or leafs. These are uses
that I'm pretty sure are no longer needed. There are a few others that will go
in the future.
Depends on D172874
Differential Revision: https://phabricator.services.mozilla.com/D172875
