The editor modules does QI too many times when it sets or removes some style
with `execCommand` or XPCOM API. Therefore, there should be an API to
retrieve `nsStyledElement` pointer from `nsINode*`.
Differential Revision: https://phabricator.services.mozilla.com/D87990
Previously, IsFocusable returned true on elements in print preview documents, but the element wouldn't accept focus.
This meant that when you tried to tab, focus would get stuck on the document.
Now, IsFocusable returns false.
Thus, tab doesn't try to stop on these elements and can move out of the document.
Differential Revision: https://phabricator.services.mozilla.com/D88000
This is backed by an existing nsPageSequenceFrame API, which this patch also
renames to use the word "Raw" for consistency across the full callstack.
Differential Revision: https://phabricator.services.mozilla.com/D87886
Now that main thread scroll updates preserve the relative scroll offset
in APZ, this hacky fix is no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D87687
Before this patch stack, nsPageSequenceFrame and every nsPageFrame each
individually tracked the number of pages.
As of the previous patch, we've coalesced the nsPageFrame variables into a
single variable that lives on nsSharedPageData. This patch here replaces
nsPageSequenceFrame's member-var with that nsSharedPageData variable, too.
Depends on D87696
Differential Revision: https://phabricator.services.mozilla.com/D87697
We already do this static_cast'ing before this patch, for a single
nsPageFrame-specific method call. This patch just captures the result of that
static_cast in a reusable variable, so that I can easily add another
nsPageFrame-specific function call in the next patch of this patch series.
(We can be confident this casting is valid, because we only ever give
PrintedSheetFrame this one type of child frame.)
Differential Revision: https://phabricator.services.mozilla.com/D87695
We do the flex algorithm by assuming the available block-size is
unconstrained. Thus, we can remove `availableBSizeForContent` and
`aStatus` passing to DoFlexLayout(), ComputeMainSize(), and
ComputeCrossSize().
Differential Revision: https://phabricator.services.mozilla.com/D87109
Although this goes against the suggestion of the sample algorithm in the
spec, this brings the layout of the multi-line column-oriented flex
container in paginated context closer to the layout with no
fragmentation. This also matches Google Chrome's behavior.
Tweak flexbox-unbreakable-child-2.html so that it matches the rendering
as of this patch. Change the height of `.muticol` and the removal of
border in `flexContainer` to let two flex items fit exactly into the
flex container's height, making reference easier to write.
Differential Revision: https://phabricator.services.mozilla.com/D87107
Likewise for RepaintRequest, and direct usages of mScrollOffset
inside FrameMetrics.
The general idea is:
* APZ's copy of the FrameMetrics stores the visual scroll offset,
so calls to GetScrollOffset() on it are replaced with
GetVisualScrollOffset()
* The layer tree's copy of the frame metrics (and copies derived
from that like mLastContentPaintMetrics) currently stores the
layout scroll offset, so calls to GetScrollOffset() on those
are replaced with GetLayoutScrollOffset().
The latter changes are particularly important, as they enable us
to modify the layer tree's copy to store (a main thread snapshot
of) the visual offset in mScrollOffset in a future patch.
This patch intends no functional changes. In the cases where we
change GetScrollOffset() to GetLayoutScrollOffset(), mScrollOffset
and mLayoutViewport.TopLeft() should already be storing the same
thing.
The patch identifies a few usages as suspicious but leaves them
functionally unchanged for now.
A few problematic usages of GetScrollOffset() remain, which will
require other fixes to remove.
Differential Revision: https://phabricator.services.mozilla.com/D87159
Note: Previously we were scaling based on the available ISize (and we were
ignoring the BSize for scaling purposes). Now we want to consider the BSize as
well, so the obvious next step would be to scale based on the available BSize -
but that doesn't work, because the available BSize is unconstrained here. (It's
unconstrained, even though we're fragmenting, because thankfully we don't
attempt to fragment the nsPageSequenceFrame itself -- we only fragment at a
level further down in the frame tree.)
So: this patch changes us to instead scale down based on the *computed* size
(rather than the available size), such that both dimensions fit. The computed
size here is the size of the scrollport; and, importantly, it has a finite
value in the block axis (unlike the *available* BSize which is unconstrained
here).
Note that the available ISize and the computed ISize are the same in this case
(they're both the ISize of the scrollport), so there's no behavior-change here
for the computation of the inline-axis-based scale factor.
Differential Revision: https://phabricator.services.mozilla.com/D87021
When <object> targets to a svg image, we use nsSubDocumentFrame. The
intrinsic ratio should be overridden by aspect-ratio while computing
its size on this frame.
This update in nsSubDocumentFrame also works in iframe.
Differential Revision: https://phabricator.services.mozilla.com/D79362
This includes a update of the ini file. I noticed the color
of the video is not equal to "rgb(0, 128, 0)" (i.e. background-color: green).
It is "rgb(1, 128. 1)" on Mac (without WebRender),
"rgb(0, 125, 0)" on Mac (with WebRender), and "rgb(1, 128, 2)" on Linux.
Perhaps it is a bug of our video rendering or video scaling. Therefore,
I added fuzzy into the ini file with max 0-3 difference per channel.
(Note: The size of this video is 50x50, so the max number of pixels is 2500.)
Differential Revision: https://phabricator.services.mozilla.com/D79337
In order to apply Automatic content-based minimum sizes, we have to know
the content size on the block axis. We cannot get the content size until
we finish the reflow of the child frames. So we have to keep a flag
which indicates the size of the ratio-dependent axis is overrideen by
aspect-ratio in ReflowInput.
We will set the correct return value in the next patch, For now, we
always return AspectRatioUsage::None.
Differential Revision: https://phabricator.services.mozilla.com/D79335
We calculate the size of ratio-dependent axis by aspect-ratio while
initializing its ReflowInput, for most of the basic block cases.
This patch doesn't include "Automatic content-based minimum sizes",
which will be handled later. Besides, replaced elements will be handled
later as well.
We don't pass abspos-004.tentative.html because there is still a
spec issue: https://github.com/w3c/csswg-drafts/issues/5151.
For other tests we didn't pass (e.g. block-aspect-ratio-009.tentative.html,
or replaced-element-00x.tentative.html), we fix them later.
Besides, in this patch, we don't handle the case if the size of
ratio-determining axis uses intrinsic size keywords (which needs to be
calculated by its content size). We will fix this in the following bug
(Bug 1646100).
Differential Revision: https://phabricator.services.mozilla.com/D78964
Note: Previously we were scaling based on the available ISize (and we were
ignoring the BSize for scaling purposes). Now we want to consider the BSize as
well, so the obvious next step would be to scale based on the available BSize -
but that doesn't work, because the available BSize is unconstrained here. (It's
unconstrained, even though we're fragmenting, because thankfully we don't
attempt to fragment the nsPageSequenceFrame itself -- we only fragment at a
level further down in the frame tree.)
So: this patch changes us to instead scale down based on the *computed* size
(rather than the available size), such that both dimensions fit. The computed
size here is the size of the scrollport; and, importantly, it has a finite
value in the block axis (unlike the *available* BSize which is unconstrained
here).
Note that the available ISize and the computed ISize are the same in this case
(they're both the ISize of the scrollport), so there's no behavior-change here
for the computation of the inline-axis-based scale factor.
Differential Revision: https://phabricator.services.mozilla.com/D87021
The frame selection changes can run script, so we need to check for the
frame itself getting destroyed. This fixes the crash as reported.
Additionally, the document check it does for pointer capture is
incorrect, it should use the composed, not uncomposed doc, so that it
works in shadow dom.
Differential Revision: https://phabricator.services.mozilla.com/D87097
That prevents preceding whitespace from getting collapsed.
When there's a single lone CR (so `a\rb`) our behavior here diverges
from Chrome's but matches Safari's. We treat it as ZWSP.
That matches the initial resolution of [1], but then there have been
various doing and undoings of that resolution, so it's not totally clear
to me what the correct behavior per spec should be. I think "treat it as
other control character"? But I haven't dug into what that implies, so
for now I've just kept behavior there as-is.
[1]: https://github.com/w3c/csswg-drafts/issues/855
Differential Revision: https://phabricator.services.mozilla.com/D86188
AFAICT the spec says that these layout scrollbars that take up no layout space that scroll the visual viewport do affect the size of the visual viewport. (Double check this)
Most other users don't care about the size of these special scrollbars.
I left nsIDOMWindowUtils::getScrollbarSize unchanged (NB different from nsIDOMWindowUtils::getScrollbarSizes which is modified by this patch) because I'm less sure. I will file a followup about it.
Differential Revision: https://phabricator.services.mozilla.com/D85708
The existing calculation will make them overlap. The AdjustOverlappingScrollbars code was written with overlay scrollbars in mind but it looks like it will work just fine for this case.
Differential Revision: https://phabricator.services.mozilla.com/D85707
Otherwise the calculation above would lead to an empty rect for the scroll corner.
The scrollbar rects as computed now still overlap each other and the scroll corner, the next patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D85706