This patch tries to mark root callers of `nsINode::GetSelectionRootContent()`
which calls `nsINode::GetAnonymousRootElementOfTextEditor()` as far as possible
(and reasonable).
It's used by `ContentEventHandler` so that a lot of methods of
`EventStateManager`, `ContentEventHandler`, `IMEContentObserver` which are main
users of it are also marked as `MOZ_CAN_RUN_SCRIPT`. I think that this is
reasonable.
On the other hand, it might not be reasonable to mark `IMEStateManager` methods
as `MOZ_CAN_RUN_SCRIPT` for initializing `IMEContentObserver` because
`IMEStateManager` may be able to initialize `IMEContentObserver` asynchronously
and its root callers are in XUL layout code. Therefore, this patch uses
`MOZ_CAN_RUN_SCRIPT_BOUNDARY` for `IMEStateManager` at least for now.
Differential Revision: https://phabricator.services.mozilla.com/D92730
This patch tries to mark root callers of `nsINode::GetSelectionRootContent()`
which calls `nsINode::GetAnonymousRootElementOfTextEditor()` as far as possible
(and reasonable).
It's used by `ContentEventHandler` so that a lot of methods of
`EventStateManager`, `ContentEventHandler`, `IMEContentObserver` which are main
users of it are also marked as `MOZ_CAN_RUN_SCRIPT`. I think that this is
reasonable.
On the other hand, it might not be reasonable to mark `IMEStateManager` methods
as `MOZ_CAN_RUN_SCRIPT` for initializing `IMEContentObserver` because
`IMEStateManager` may be able to initialize `IMEContentObserver` asynchronously
and its root callers are in XUL layout code. Therefore, this patch uses
`MOZ_CAN_RUN_SCRIPT_BOUNDARY` for `IMEStateManager` at least for now.
Differential Revision: https://phabricator.services.mozilla.com/D92730
Where an adjustment (to reflect a delta between the APZ and layout
scroll offsets) is necessary, the inputs needed to compute the
adjustment are stored with the margins, and the adjustment is
applied at query time.
A couple of notes on this patch:
* Storing DisplayPortMargins::mLayoutOffset is probably unnecessary,
we should be able to just query the scroll frame's layout offset
when applying the margins.
* Some callers of DisplayPortMargins::WithNoAdjustment() may be
incorrect, in that they pass in margins that are relative to the
visual viewport but do not make a corresponding adjustment.
This is a pre-existing issue that this patch just makes clearer.
As this is a regression-prone area, this patch is careful to avoid
making any functional changes, leaving the above issues to be
addressed in future bugs.
Differential Revision: https://phabricator.services.mozilla.com/D92506
The audio/video controls element has touch listeners on the scrubber, which
steals events when we don't want it to. So let's ignore those listeners.
Ignoring system group listeners for the purposes of event retargeting seems
reasonable in the general case, because those listeners are coming from the
browser itself. If we're relying on the event retargeting to make those browser
elements easy to hit, then we should not be doing that and instead just make
them bigger.
Test coverage for this change is provided by the android-components tests that
failed in bug 1668112. The next patch re-enables touch event retargeting and
exercises this code in the context of those tests.
Depends on D92436
Differential Revision: https://phabricator.services.mozilla.com/D92437
The only caller passed in DisplayRelativeTo::ScrollFrame.
Removing this makes it easier to consolidate display port options
in a subsequent patch.
Differential Revision: https://phabricator.services.mozilla.com/D92014
Keyboard arrow key scrolls go through PresShell::ScrollLine/ScrollCharacter. When these look for a scroll frame they eventually end up at nsLayoutUtils::GetNearestScrollableFrameForDirection.
nsLayoutUtils::GetNearestScrollableFrameForDirection does two things wrong when determining if the scroll frame is scrollable by apz: it disallows overflow hidden scrolling, and it uses GetAvailableScrollingDirections which is based on the layout scroll range.
Using GetAvailableScrollingDirectionsForUserInputEvents takes into account both of these factors.
GetNearestScrollableFrameForDirection is used by:
-gfx/layers/apz/src/FocusTarget.cpp
-EventStateManager::DoContentCommandScrollEvent
-PageMove, ScrollPage, ScrollLine, ScrollCharacter, CompleteScroll of PresShell
All of these should want the more apz aware function.
Differential Revision: https://phabricator.services.mozilla.com/D90498
The frame we pass to PageMove is used to extend the selection, we can't extend a selection outside of the document. The scrolling that takes place can still scroll scroll frames in parent documents afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D92176
The math-depth implementation is refined to take into account the
ScriptPercentScaleDown and ScriptScriptPercentScaleDown constants (if the
parent's first valid font has a MATH table) in order to calculate the
scale factor between math-deth 0 and 1, and between 0 and 2 respectively.
Behavior is unchanged if the legacy scriptsizemultiplier attribute is
specified or if no MATH table is available.
The preference layout.css.math-depth.enabled remains disabled in nightly
until the remaining bit (support for font-size: math) is implemented in
bug 1667090.
Differential Revision: https://phabricator.services.mozilla.com/D91604
This patch fixes two issues, described below:
First, the GetTopLevelDocument function was looking at the browsing
context tree. It should look at the window context tree, as looking at
the browsing context tree means that if you're in a discarded or
about-to-get-discarded document, you can end up with a document from a
different tree. Computing intersections between those of course makes no
sense and triggers the assertion we're enabling.
Second, this patch fixes an issue when you have fission enabled, and a
setup such as:
A1 -> B1 -> A2
If you try to use IntersectionObserver from A2 with the implicit root,
we'd end up with:
* rootRect: A1's root scrollport rect (this is fine, because it's only
used to compute the root margin and bounds and so on, not
to compute geometry).
* rootFrame: A1's root scroll frame (this is _not_ fine, see below).
Then, we'd try to map rects from A2's target to A1's viewport, and we
can't really do that sensibly with the existing nsLayoutUtils functions,
because we're not accounting for all the OOP iframe transforms that may
be going on. This also triggers the assertion that this patch enables in
same-origin-grand-child-iframe.sub.html.
To fix it, for the A2 case, use the same code that we have for other OOP
iframes. The test tweaks fails with fission enabled without the patch
(because we don't account for the OOP iframe clip).
Differential Revision: https://phabricator.services.mozilla.com/D92089
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
In many cases with wpt, most of the tests in the file pass, but it is rather time consuming to annotate
.ini files case by case.
Differential Revision: https://phabricator.services.mozilla.com/D91977
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
And enable the assertion for the same-document case.
Without this patch, the assertion would fire in tests like
gfx/layers/apz/test/mochitest/test_group_zoom.html, where stuff like
MaybeHandleEventWithAccessibleCaret, which passes a non-root-frame down
here, and a target, which ends up violating the preconditions of
ClipToFrame, etc.
Enable the assertion for the same-document case, there are other
violations when fission is enabled in the cross-document case.
Differential Revision: https://phabricator.services.mozilla.com/D91966
This allows it to be forward-declared (while a nested class cannot be),
such that headers files that use RectCallback by pointer or reference
do not need to include nsLayoutUtils.h.
This avoids including nsLayoutUtils.h in nsRange.h.
Differential Revision: https://phabricator.services.mozilla.com/D91685
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
Right now the BoxToRect callback assumes that when it gets a
RECTS_ACCOUNT_FOR_TRANSFORMS flag, the "relative to" is an ancestor.
This holds for all the callers of GetAllInFlowRectsUnion except for [1],
which was introduced in bug 1581876, because they pass
GetContainingBlockForClientRect (that is, the root frame) as the root.
But that caller passes target, so IB split continuations or such would
get two siblings as the from/to frames, messing up the bounds.
An alternative would be to not pass the RECTS_ACCOUNT_FOR_TRANSFORMS
flag for that call (as it's computing a rect relative to self, but I
don't think that'd be quite correct in the presence of fragmentation
with transformed containers (if that's possible at all? would need to
think harder...)), but it seems like the API should just behave more
generally, or assert otherwise.
To that effect, this patch adds an assertion to TransformRectToAncestor
that would've caught this bug (though there are some pre-existing
violations, so we'll fix them in another bug).
[1]: https://searchfox.org/mozilla-central/rev/dfd9c0f72f9765bd4a187444e0c1e19e8834a506/dom/base/DOMIntersectionObserver.cpp#340-341
Differential Revision: https://phabricator.services.mozilla.com/D91883
Also rename it to IsXULDisplayStyle() because nsStyleDisplay often has
"Style"-suffix for related helpers.
(Note: IsXULDisplayType() is not used in GetAspectRatio() in the final
revision, but this part is still a good simplification.)
Differential Revision: https://phabricator.services.mozilla.com/D91228
For now, GetAspectRatio() is just an alias for GetIntrinicRatio(). In
Part 7, we're going to have GetAspectRatio() consider aspect-ratio
property so that each replaced elements only need to report their
intrinsic ratio via GetIntrinicRatio(). Non-replaced element can also
call GetAspectRatio() to get the ratio suitable to calculate layout
size.
As of this patch, all the replaced elements'
GetIntrinsicRatio() (including nsImageFrame::mIntrinsicRatio) consider
aspect-ratio properties (added in bug 1639963). This is wrong, because
it affects replaced element's content ratio. So we adapt only callers
[1] involving the computation of the frame's external sizes to retain
the behavior after Part 7.
This change shouldn't change behavior.
[1] Exceptions include 1) a caller in nsIFrame::ComputeSize() checking
the frame has no intrinsic ratio; 2) other frame classes implementing
nsIFrame::GetIntrinsicRatio() by calling their parent's
GetIntrinicRatio(). nsSubDocumentFrame::GetIntrinicRatio() is an
example.
Differential Revision: https://phabricator.services.mozilla.com/D91227
Masayuki Nakano
Emilio Cobos Álvarez
Sylvestre Ledru
Kris Maglione
Denis Palmeiro
Kartikaya Gupta
Narcis Beleuzu
Botond Ballo
Daniel Holbert
Edgar Chen
Timothy Nikkel
Cameron McCormack
Razvan Maries
Frederic Wang
Gerald Squelart
Olli Pettay
Bogdan Tara
Jonathan Watt
Ting-Yu Lin