Now that we don't include overflow in outlines (bug 1739894) the
overwhelmingly common case is that innerRect == GetRectRelativeToSelf(),
except on a couple special cases.
Avoid storing the property in those cases. The test introduced in the
patch above still ensures we invalidate rendering correctly even without
the presence of the assert.
Depends on D141320
Differential Revision: https://phabricator.services.mozilla.com/D141321
This doesn't change behavior but makes some code a bit nicer to read and
documents some of the code that wasn't obvious otherwise.
Differential Revision: https://phabricator.services.mozilla.com/D141236
This doesn't change behavior just yet, but seems worth doing separately.
With this patch, we can render content overlaid on top of an image
frame, by attaching a shadow root to it. The idea is to use this for
text recognition (OCR) of text inside images.
I chose to implement this using the DynamicLeaf stuff that I removed in
bug 1746310 (because nsMenuPopupFrame was its only user).
That seems simpler than either a new frame class, or more special cases
in the frame constructor, etc. But let me know if you disagree.
There are further changes that we want to do. For example, trying to
select the overlaid text with the mouse right now will start dragging
the image. For that, we might need to tweak our selection / mouse
dragging code. But those seem all changes that can go on top of this.
Differential Revision: https://phabricator.services.mozilla.com/D140638
None of these changes should change the behavior.
- In `ConsiderChildOverflow()`, replace the legacy term "visual" overflow.
- `GetOverflowAreasRelativeToSelf()`, `ScrollableOverflowRectRelativeToSelf()`,
`InkOverflowRectRelativeToSelf()` can really be terser.
- Replace `mRect.TopLeft()` with `Position()`, and
`nsRect(nsPoint(0, 0), GetSize())` with `GetRectRelativeToSelf()`, making them
shorter and clearer.
- Move `GetOverflowRect()` to private section because it's an implementation
detail of `InkOverflowRect()` and `ScrollableOverflowRect()`.
Differential Revision: https://phabricator.services.mozilla.com/D140437
When a position:sticky element "sticks" in the scroll container's scrollport, we
compute its containing block's overflow areas by including its overflow areas
located at its relative position. This makes the element's normal position
unreachable because its overflow areas located at its "normal position" might
not be within its containing block's overflow areas. Block frame doesn't have
this problem because `nsLineBox` always includes the element's normal position
rect in its own rect.
Therefore, when including a sticky child frame's overflow area into its parent's
overflow area, the overflow areas located at its normal position should be
included as well. This behavior is consistent with a relatively positioned child
frame. (A position:relative frame's normal position is always reachable when
scrolling, at least in both axes that grow positively.)
Differential Revision: https://phabricator.services.mozilla.com/D140373
`nsIFrame::IsRelativelyPositioned()` tests "position:relative" or
"position:sticky", but its naming is misleading until you've dug into the
underlying helper `nsStyleDisplay::IsRelativelyPositionedStyle()`.
Differential Revision: https://phabricator.services.mozilla.com/D140273
We already call MaybeQueueCacheUpdateForStyleChanges from DidSetComputedStyle for reconstructed frames.
However, at that point, nsIContent::GetPrimaryFrame (and thus LocalAccessible::GetFrame) returns null, which means we're unable to check for style changes.
Instead, we now handle style changes for reconstructed frames in PruneOrInsertSubtree, at which point the frame is definitely available.
Differential Revision: https://phabricator.services.mozilla.com/D138627
This adds a round trip from double -> float -> double because
CSSRect is float but it should be ok because most users of gfxRect (RectDouble)
should be using Rect instead anyways.
Differential Revision: https://phabricator.services.mozilla.com/D137811
Depends on D136163
I have a feeling this isn't exactly the right way to pass this info, since the old WR code must have known about the perspective node without using my new flag.
Differential Revision: https://phabricator.services.mozilla.com/D136180
This shouldn't change behavior but makes following the code a bit
easier. There's no point in using callbacks for touch-action as:
* We return the computed flags anyways.
* Each caller wants to do something different.
* (more importantly) The callback gets called synchronously.
So move the relevant code to TouchActionHelper and make the callers deal
with the flags as they please. I've preserved the behavior of only doing
the thing if the flags array is non-empty.
Differential Revision: https://phabricator.services.mozilla.com/D134933
The assertion here was added during the iterator refactoring in bug 1732349,
but is actually bogus. The old code would have returned via the MOZ_TRY_VAR
that wrapped the call to blockFrame->GetLineNumber(); that's replaced by
iter->FindLineContaining(), so we should now check for an error there and
similarly just return to the caller, not assert.
Differential Revision: https://phabricator.services.mozilla.com/D134950
Bug 1550869 made all the non-editable images return a `FrameTarget` with
`userFrameEdge=true`. When the user moves the mouse pointer to select an image
from its left edge, the mouse pointer needs to reach the right edge of the image
in order to complete the selection. This makes it difficult to select an image
at the end of a line.
This patch restores the behavior to select a non-draggable & non-editable image
to it was before bug 1550869. That is, we recognize the image selection when the
mouse pointer moves passed the middle point of the image
width (`OffsetsForSingleFrame`). Both blink and webkit have the same behavior,
but no spec text dictates this behavior, so I mark the wpt test as "tentative".
Differential Revision: https://phabricator.services.mozilla.com/D133960
It's hard to fix some callers. Therefore, in this bug, we should fix only
simple cases. Therefore, we should rename existing API first.
Differential Revision: https://phabricator.services.mozilla.com/D131334
Building with --disable-xul has been busted since _at least_ bug
1082579, for more than 7 years (I didn't try to track that down
further). It's time to recognize that the option serves no purpose.
Differential Revision: https://phabricator.services.mozilla.com/D133161
Applying it to SVG-transformed frames is wrong, and causes us to
rasterize rather massive SVGs. This is consistent with the other CSS
3d transforms code, and our rendering of the test-case matches other
browsers.
Differential Revision: https://phabricator.services.mozilla.com/D132040
This causes (among other things) pages to be dark when using regular
windows system colors and forcing colors to "always", which is nice.
Differential Revision: https://phabricator.services.mozilla.com/D131165
Keep old behavior behind a pref.
I've kept the tests that failed enabling the pref because they're
somewhat hard to rewrite and I'd rather avoid that until we know this
will stick, specially since they test the guts of the recursive function
that I'm basically ~disabling.
I've checked that the rendering on those is sensible / matches other
browsers.
Differential Revision: https://phabricator.services.mozilla.com/D130717
Keep old behavior behind a pref.
I've kept the tests that failed enabling the pref because they're
somewhat hard to rewrite and I'd rather avoid that until we know this
will stick, specially since they test the guts of the recursive function
that I'm basically ~disabling.
I've checked that the rendering on those is sensible / matches other
browsers.
Differential Revision: https://phabricator.services.mozilla.com/D130717
