HasResizer() is equivalent to mResizerBox and is used only within
ScrollFrameHelper, so no need to expose it. Also, remove some unreachable
if-branches.
Differential Revision: https://phabricator.services.mozilla.com/D133693
Revise vRect & hRect computation because the scrollbar gutter can be at both
inline start and inline end sides. For example, we can no longer use
`aInsideBorderArea.width - mScrollPort.width` to get the actual width of the
vertical scrollbar. We want to compute them in different ways.
Differential Revision: https://phabricator.services.mozilla.com/D133692
Compute the actual vertical & horizontal scrollbars' rects (vRect & hRect) only
when we decide to show the scrollbars. The rationale is that after introducing
scrollbar-gutter in bug 1715112, `mScrollPort` is no longer equal to
`aInsideBorderArea` even if we don't show scrollbars, and we want scrollbar
rects remaining empty to avoid showing them.
Simplify `hasVisualOnlyScrollbarsOnBothDirections` and move it closer to its
first usage.
Differential Revision: https://phabricator.services.mozilla.com/D133691
Currently, we use IsPhysicalLTR() to query which is the start side of the
physical left <-> right axis. However, for vertical row-oriented flex
containers, physical left <-> right axis is its cross axis. We really should
query IsBidiLTR() instead because its main axis is parallel to line-left <->
line-right axis (i.e. inline axis).
flexbox-justify-content-wmvert-003.html is adapted from
flexbox-justify-content-wmvert-002.html.
Differential Revision: https://phabricator.services.mozilla.com/D133168
This patch integrates OffscreenCanvasDisplayHelper with
HTMLCanvasElement, OffscreenCanvas and nsDisplayCanvas to allow
asynchronous display of an OffscreenCanvas.
Differential Revision: https://phabricator.services.mozilla.com/D130787
This patch integrates OffscreenCanvasDisplayHelper with
HTMLCanvasElement, OffscreenCanvas and nsDisplayCanvas to allow
asynchronous display of an OffscreenCanvas.
Differential Revision: https://phabricator.services.mozilla.com/D130787
For reducing the legacy behavior emulator of `nsContentUtils::ComparePoints`
and make it simpler, this patch makes it take `int64_t` as the offset.
Additionally, it's named "ComparePoints_AllowNegativeOffsets`.
Differential Revision: https://phabricator.services.mozilla.com/D132549
This patch fixes only the cases if the result of `ComputeIndexOf_Deprecated()`
is used as unsigned integer with implicit or explicit cast.
Differential Revision: https://phabricator.services.mozilla.com/D131336
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
They are defined as "unsigned long" by the standards. So we should use
`uint32_t` rather than `int32_t` with the methods. However, layout code
uses `int32_t` a lot for representing the offset. Therefore, this patch
adds `*_FixOffset1` etc for the cases which cannot fix easily in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D131110
It's an internal API corresponding to `Selection.getRangeAt` DOM API.
I think that it should use `uint32_t` rather than `size_t` because of the
consistency with the DOM API and `Selection::RangeCount()`.
This patch fixes all callers of `GetRangeAt()`, and rewrites it with ranged-
loops unless original ones do not refer `RangeCount()` every time and may run
script in the loop.
Differential Revision: https://phabricator.services.mozilla.com/D128848
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
The basic part of the infrastructure of scroll-linked animations. This is
designed based on scroll-linked animation generated by CSS. We will
implement the timing computation and hook the ScrollTimeline to the CSS
animations in the following patches.
All the tests are in the patch that hooks ScrollTimeline to CSS Animation.
Differential Revision: https://phabricator.services.mozilla.com/D129100
This patch is inspired by `ScrollFrameHelper::GetActualScrollbarSizes()` that
uses a nsMargin to represent the space occupied by scrollbar.
In bug 1715112, TryLayout is going to consider the space occupied by the
scrollbar gutter. Hence the variable name with gutter in it just to avoid change
the variable name again.
Differential Revision: https://phabricator.services.mozilla.com/D132663
The static AddRemoveScrollbar() helper is meant to adjust the scroll port and
test whether the scrollbar fits, but its interface is obscure. By expanding the
helper in-place, the code should now become easy to follow, and we can also
remove the wordaround that sets the bool:1 bitfield.
Differential Revision: https://phabricator.services.mozilla.com/D132759
Previously with ImageContainers, we would put the new preferred surface
into the ImageContainer. When we check if we should invalidate, it would
have a different image key, and hence invalidate the image frame and
schedule a paint.
With ImageProviders, it returns the same key in this case, because the
ImageProvider represents a particular surface. As such, we need to
actually track when we get a substituted ImageProvider, and invalidate
the image frame more aggressively to ensure we get the preferred size.
Differential Revision: https://phabricator.services.mozilla.com/D132583
I considered removing this class initially, but it's actually a pretty
useful abstraction over the DateTimeFormat interface when used
specifically with Gecko. It applies the OS preferences and provides some
caching behavior.
Differential Revision: https://phabricator.services.mozilla.com/D131671
-Wshadow warnings are not enabled globally, so these -Wno-shadow suppressions have no effect. I had intended to enable -Wshadow globally along with these suppressions in some directories (in bug 1272513), but that was blocked by other issues.
There are too many -Wshadow warnings (now over 2000) to realistically fix them all. We should remove all these unnecessary -Wno-shadow flags cluttering many moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D132289
Technically, `aContentArea` is not 100% wrong; its the content area of the outer
scroll frame, which contains the content area of the inner scrolled frame, the
padding, and the scrollbars. However, it should really be named
`aInsideBorderArea` as the caller names it. Otherwise, it is easy to cause
confusion with the content area of the inner scrolled frame.
Also, rename `aOldScrollArea` as well so that we use the term "scroll port"
consistently.
Differential Revision: https://phabricator.services.mozilla.com/D132445
Scrollbar's min and pref sizes won't change during reflow, so we can cache them
in ScrollReflowInput to save some repetitive computation in multiple
ReflowScrolledFrame() and TryLayout() calls.
This is also a preparation for Bug 1715112 because we can use the pref sizes to
compute the scrollbar-gutter size in ScrollReflowInput.
Differential Revision: https://phabricator.services.mozilla.com/D132443
It should be sufficient to call `SetScrollbarMediatorContent` once in
ScrollReflowInput's constructor, which is created in the beginning of
nsHTMLScrollFrame::Reflow(), instead of calling it repeatedly in multiple
TryLayout() calls.
Differential Revision: https://phabricator.services.mozilla.com/D132442
We've had some APIs passing ScrollReflowInput by reference while some others
using pointer. Let's unify them by using reference everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D132441
They shouldn't be scattered in nsHTMLScrollFrame::Reflow(). Also, reorder these
assignment operations according to the member variables' appearance order in
ScrollReflowInput.
I also moved the constructor out of the class definition because it becomes a
large method, and I'm going to add `private:` section after the methods section
in a later patch.
Differential Revision: https://phabricator.services.mozilla.com/D132440
I considered removing this class initially, but it's actually a pretty
useful abstraction over the DateTimeFormat interface when used
specifically with Gecko. It applies the OS preferences and provides some
caching behavior.
Differential Revision: https://phabricator.services.mozilla.com/D131671
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
Given the compat reports in bug 1484928, I don't think it's worth
keeping the current behavior.
Our behavior should match other browsers now. Rather than making
content: url() work everywhere even for otherwise-replaced elements,
just special-case this since that's what other browsers seem to do.
Differential Revision: https://phabricator.services.mozilla.com/D131797
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
This patch potentially changes the behavior when the scrolled frame is in
vertical writing-mode, but it should be the correct way to handle the scrollbar
change.
Differential Revision: https://phabricator.services.mozilla.com/D130711
LineBreaker::Strictness is just an alias of LineBreakRule in Segmenter.h. This
is to reduce the dependency of the legacy LineBreaker.
Differential Revision: https://phabricator.services.mozilla.com/D131026
LineBreaker::WordBreak is just an alias of WordBreakRule in Segmenter.h. This is
to reduce the dependency of the legacy LineBreaker.
Differential Revision: https://phabricator.services.mozilla.com/D131025
test_abort_smooth_scroll_by_instant_scroll.html in this comment is a test case
to make sure this change doesn't regress a case where a smoothe scrolling run
by an APZC is replaced by an instant scroll operation by script.
Some other mochitests for this change are in the next commit.
Differential Revision: https://phabricator.services.mozilla.com/D129594
In some platforms (like macOS, windows dark mode, android, and some gtk
themes) the foreground selection color might be `currentcolor`, and that
doesn't generally guarantee enough contrast with the attention
background.
Remove HeadlessLookAndFeelGTK's handling of this color since it's
useless (always overridden by prefs in all.js)
Differential Revision: https://phabricator.services.mozilla.com/D130617
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
The optimized code path for nested grid layout should only set the
BSize of the child frames, since this is what the optimization is
for.
Without the change, the ISize is always going to be set to 0 for
child frames which may break the layout. Sometimes, it is not
an issue because the ISize of the grid area gets updated, so
the cached measurement becomes invalid, and the ISize of the child
frame gets set to the correct one again.
Differential Revision: https://phabricator.services.mozilla.com/D130828
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
Both ScrollToCSSPixels and ScrollByCSSPixels are called only from JS via
Element.scrollTo, Element.scrollTop, Element.scrollLeft, Window.scroll,
Window.scrollTo and Window.scrollBy.
Note that we don't target either Window.scrollByLines or Window.scrollByPages
(both end up calling ScrollFrameHelper::ScrollBy) because both are triggered by
user interactions for our XUL tree implementation, for example
Window.scrollByLines gets called in response to a DOMMouseScroll event in
tree.js [1].
[1] https://searchfox.org/mozilla-central/rev/a12c2c2e59c92d8f969d8f3f290ab16919449c9d/toolkit/content/widgets/tree.js#788
Differential Revision: https://phabricator.services.mozilla.com/D130418
There are 4 call sites of the function, Element::Scroll, Element::SetScrollTop,
Element::SetScrollLeft and nsGlobalWindowInner::ScrollTo. None of call sites
specifies ScrollOrigin.
Differential Revision: https://phabricator.services.mozilla.com/D130416
In the conditions where we hit this partiuclar codepath, the spec used to
require us to align within the grid's padding box (which is what we were trying
to do[1]), but now it requires us to align within the grid's content box.
This patch makes us start passing a bunch of WPT tests (whose .ini files I'm
removing here).
This patch also changes the reference case for some "last-baseline"-specific
tests in the same directory, by cribbing the "alignEnd" rule from the
neighboring non-"last-baseline" analog (since "last-baseline" falls back to end
alignment and is meant to be equivalent in these testcases). Before this
patch, the affected reference cases were inadvertently depending on the Firefox
bug that I'm fixing here, and they were expecting the testcase's end-aligned
content to be at the wrong position as a result. Chromium developers fixed
this issue in the neighboring non-"last-baseline" tests in [2], but they didn't
catch the files that I'm fixing here, because Chromium doesn't implement "last
baseline" alignment yet.
[1] Before this patch, we actually weren't quite aligning within the
padding-box, even though we were trying to. We were computing an alignment
offset based on the size of the padding box, and then we were using that offset
as a position within the *content box*. This could result in us pushing
end-aligned content outside the grid entirely, as in the testcase on the bug
report for this bug.
[2] https://chromium-review.googlesource.com/c/chromium/src/+/2803842
Differential Revision: https://phabricator.services.mozilla.com/D130713
With the rewrite, we reduce the dependency of lwbrk LineBreaker::Next(),
WordBreaker::Next(), and their `int32_t` sentinel values
NS_LINEBREAKER_NEED_MORE_TEXT and NS_WORDBREAKER_NEED_MORE_TEXT.
Differential Revision: https://phabricator.services.mozilla.com/D130392
With the rewrite, we reduce the dependency of lwbrk LineBreaker::Next(),
WordBreaker::Next(), and their `int32_t` sentinel values
NS_LINEBREAKER_NEED_MORE_TEXT and NS_WORDBREAKER_NEED_MORE_TEXT.
Differential Revision: https://phabricator.services.mozilla.com/D130392
These are only used for frameset painting and the non-e10s <select>
dropdown focus codepath. We have other more appropriate standard
colors for this.
Differential Revision: https://phabricator.services.mozilla.com/D129992
As we don't support multi-line text in SVG, there's no point running the line-breaker and
collecting potential break positions for textframes that are part of an SVG text subtree.
Telling BuildTextRunsScanner to skip this makes it somewhat less expensive.
In my local build, this reduces the reflow time of the testcase from nearly 20s to about 4.5s.
Still much too long, but at least it's a step in the right direction.
Differential Revision: https://phabricator.services.mozilla.com/D129404
This patch clamps the `resolvedMinSize` before the size is passed into
`UpdateMainMinSize`, which is where the assertion is triggered.
Also, tweak the MOZ_ASSERT a bit because it's best to test an nscoord is
not NS_UNCONSTRAINEDSIZE before invoking comparison operator.
Differential Revision: https://phabricator.services.mozilla.com/D129230
Windows on dark mode uses a semi-transparent selection background like macOS,
which is basically the proton accent color. Avoid totally indistinguishable
backgrounds by ensuring there's at least minimal background contrast when
NS_SAME_AS_FOREGROUND_COLOR is used.
Differential Revision: https://phabricator.services.mozilla.com/D128757
For that:
* Remove support for caching resizer styles, since they don't seem
common enough to warrant it, unlike all other scrollbar parts.
* Make scrollcorners have pointer-events: none with overlay scrollbars,
so that the setup works / we can assert that if we have overlay
scrollbars then we don't care about the pointer-events value on
ancestors.
Differential Revision: https://phabricator.services.mozilla.com/D128772
This code was added in bug 1031107 back when we didn't have apz on desktop, and even on android apz was not reported as enabled because we were using the java pan zoom code (https://bugzilla.mozilla.org/show_bug.cgi?id=1031107#c20).
Looks like the goal of this code was to improve performance when tiling was enabled (splitting up layers into tiles). The code to actually do this tiling appears gone now, so we shouldn't need this.
We can further ask if something might be depending on this code even though it's not related to tiling. The layers.enable.tiles pref is enabled on mac and android, so we'd have bugs on Linux and mac if that were true. Further, the only places that apz is disabled now is popups that do not have remote content in them, and the only scroll frames that are IsAlwaysActive are root scroll frames of root content documents (in process). If addons put an iframe in a popup I think it has to be remote, and I don't think we have any content documents in popups, and if we did and there was a problem with removing that code we'd already have that problem on Linux and Windows. So this should be safe to remove.
Differential Revision: https://phabricator.services.mozilla.com/D127635
This was pre-existing but caught by some scrollbar-width tests. A
test-case that reproduces on current nightly:
data:text/html,<html style="overflow: scroll; scrollbar-color: red red; scrollbar-width: thin">
Toggling the `scrollbar-width` declaration in devtools doesn't change
the effective scrollbar width. Ensure we correctly reflow the scrollbars
in this case.
Differential Revision: https://phabricator.services.mozilla.com/D128515
Use imgINotificationObserver to get notified of size availability.
Layout uses an observer to wait for this too. Our observer is notified
after layout so we should have bounds by then.
We need to store the request status because we get a lot of "replayed"
status changes that would cause chatty and wrong state change events
when the accessible is first created and bound to parent.
We can use that status for both INVISIBLE and ANIMATED states in
NativeState.
Differential Revision: https://phabricator.services.mozilla.com/D127719
`nsTextFragment` is a storage of data node and DOM offset is `uint32_t`, but
some methods of `nsTextFragment` takes `int32_t` for the offset/length in
its text. Therefore, callers need to cast from `uint32_t` to `int32_t` if
the offset value is offset in a DOM node. Therefore, all methods of it should
take `uint32_t` values as offset/length in its text.
Differential Revision: https://phabricator.services.mozilla.com/D127923
Use imgINotificationObserver to get notified of size availability.
Layout uses an observer to wait for this too. Our observer is notified
after layout so we should have bounds by then.
We need to store the request status because we get a lot of "replayed"
status changes that would cause chatty and wrong state change events
when the accessible is first created and bound to parent.
We can use that status for both INVISIBLE and ANIMATED states in
NativeState.
Differential Revision: https://phabricator.services.mozilla.com/D127719
nsIScrollableFrame::IsScrollingActive basically means "has this scroll frame been scrolled recently or is this the root scroll frame". Neither of which is relevant when we are async scrolling a scrollframe on the compositor.
What determines if we can scroll a scroll frame async is ScrollFrameHelper::mWillBuildScrollableLayer, aka nsIScrollableFrame::IsMaybeAsynchronouslyScrolled.
The code in nsDisplayStickyPosition::GetStickyScrollContainer already mostly neuters nsDisplayStickyPosition is this isn't the case, this just takes it one step further.
This also removes one more user of nsIScrollableFrame::IsScrollingActive, there are only a handful left.
Differential Revision: https://phabricator.services.mozilla.com/D126427
Use imgINotificationObserver to get notified of size availability.
Layout uses an observer to wait for this too. Our observer is notified
after layout so we should have bounds by then.
We need to store the request status because we get a lot of "replayed"
status changes that would cause chatty and wrong state change events
when the accessible is first created and bound to parent.
We can use that status for both INVISIBLE and ANIMATED states in
NativeState.
Differential Revision: https://phabricator.services.mozilla.com/D127719
ReflowOutput can accept any writing mode or ReflowInput passed to its
constructor, so a caller can pass a writing mode that is more convenient
to retrieve the size.
After reflowing flex items, we want to cache its metrics in flex item's
writing mode, so we pass item's ReflowInput into ReflowOutput. However,
for out-of-flow children, we can change ReflowOutput to use flex
container's writing mode by convention.
Differential Revision: https://phabricator.services.mozilla.com/D127913
With the old layers backend we had low precision buffer code controlled via the pref layers.low-precision-buffer that was used on android. We would expand the displayport by 4x and then paint it as 1/4 the resolution, and then we would have a critical displayport without the 4x multipler that we would paint at the real resolution. The code to do the painting at the lower resolution was in the layers backend and has since been removed. (This is okay because webrender doesn't rasterize all of the content in the displayport.) So the critical displayport or displayport are no longer treated differently anywhere. Except a few pieces of code that should be fixed/changed/removed. This patch being one of them.
GetHighResolutionDisplayPort would return the displayport without the multipler in all situations (pref on or off).
In DisplayPortUtils we are checking the displayport rect before/after setting new displayport margins to see if it changes to determine if we need to invalidate. Since the critical displayport isn't used for anything, the regular displayport is the correct thing to use here.
In nsGfxScrollFrame we are doing a similar thing, except checking that the displayport doesn't change after a scroll.
In nsDisplayListBuilder::OutOfFlowDisplayData::ComputeVisibleRectForFrame it's also the correct thing, as we want to include the same rect for fixed content as we do for non-fixed content. But this is an significant expansion of the dirty rect of fixed content and the code history has fixes related to drawing too much of fixed content and OOMing so a little more scrutiny is reasonable. However if there was a problem with OOM, since this is the same rect we use for non-fixed content we would have OOM problems with regular content, so this should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D127344
This reverts the patch for bug 1720621.
This caused a conflict with the fix for bug 1722890, which fixed another case
of cutoff content when printing scaled. That fix should also cover the upscaled
case.
Differential Revision: https://phabricator.services.mozilla.com/D127594
In bug 1731929 we added this value, here we give it the value we want for child processes. I think the code comments should explain it.
Differential Revision: https://phabricator.services.mozilla.com/D126629
This patch doesn't change any user-observable behavior.
StaticAutoPtr lets us remove a handful of explicit 'delete' statements, by
making deletion happen automatically when these variables are cleared.
Differential Revision: https://phabricator.services.mozilla.com/D127337
This patch shouldn't change behavior at all.
This patch replaces a manual NS_ADDREF call with typesafe code that manages the
reference count for us. This reduces repeated boilerplate code, in the
implementation as well as the callsites.
Differential Revision: https://phabricator.services.mozilla.com/D127179
This patch shouldn't change behavior at all.
This patch replaces a manual NS_ADDREF call with typesafe code that manages the
reference count for us. This reduces repeated boilerplate code, in the
implementation as well as the callsites.
Differential Revision: https://phabricator.services.mozilla.com/D127179
We store this new bit in nsIFrame instead of in ReflowInput to record a
change to padding (inspired by the mHasBSizeChange bit). That is because
we may construct a ReflowInput more than one time before reflowing the
frame. The first construction of ReflowInput (in
SizeComputationInput::InitOffsets) will update
nsIFrame::UsedPaddingProperty() using the latest style data, so
we *cannot* determine the padding change in any of the subsequent
construction of ReflowInput.
dynamic-change-inline-size-001.html is the scenario fixed by
bug 1307853. We've already passed this test without this patch.
dynamic-change-inline-size-002.html is equivalent to 001.html except
it's written with "box-sizing:content".
dynamic-change-inline-size-003.html is adapted from testcase 2 in bug
1729122 comment 4. Both tests pass after this patch.
Differential Revision: https://phabricator.services.mozilla.com/D126422
I'm not aware of any reason we shouldn't do this, as it is interoperable
with other browsers, and it causes compat issues from sites that forget
to use the prefixed version.
Note this removes some #[parse(aliases)]. These only affect devtools
autocomplete behavior, and we avoid autocompleting -moz-prefixed
keywords when possible, so even though it's a slight behavior change,
it's worth it.
Differential Revision: https://phabricator.services.mozilla.com/D126718
We only need the actual iterator once, to get the line number; subsequently, we can use
the new CanProvideLineIterator method to check if we've found a block frame without
paying the cost of actually initializing it.
This eliminates the last remaining caller of nsIFrame::GetLineNumber, so that method
(which is prone to inefficient usage) can be removed altogether.
Differential Revision: https://phabricator.services.mozilla.com/D126532
This means nsBlockFrame::GetLineIterator is also infallible, so callers that know
they're dealing with an nsBlockFrame (not an arbitrary nsIFrame) don't need to
check for null.
Differential Revision: https://phabricator.services.mozilla.com/D126470
Previously, to check whether two frames were on the same line, you had to call nsIFrame::GetLineNumber on both of them.
If the lines were in a different containing block, this wastefully created line iterators.
With this new method, you can get the containing blocks for both frames and only create a single line iterator if the blocks are the same.
To achieve this, nsIFrame::CanProvideLineIterator was also added and is used by GetContainingBlockForLine.
Accessibility will use this new functionality in its new text boundary implementation.
Differential Revision: https://phabricator.services.mozilla.com/D126433
One caveat is that this change doesn't mean we handle frame visibility in
iframes in a same manner regardless whether the iframe is out-of-process or not.
In fact, we handle OOP iframe cases in a slightly different way since in OOP
iframes if the iframe is invisible because it's scrolled out or some such, then
we can't tell how far the iframe is from the visible scroll port. For example;
```
<div style="height: 100px; overflow: scroll;">
<div id="spacer" style="width: 100%; height: 200px;"></div>
<iframe style="height: 100px;"></iframe>
</div>
```
In this case, we consider all frames inside the iframe are invisible because
the iframe position is out of our frame visibility tracking margins. But if
the #spacer element's height is 100px, we consider all frames inside the iframe
viewport are visible if the iframe is in-process iframe, whereas we consider
all frames are invisible if the iframe is out-of-process iframe.
So in short, the frame visibilityn inside OOP iframes is depending on whether
the iframe gets painted in the parent document, i.e. depending on display port
and other factors controlling the paint stuff, the visibility inside in-process
iframes is depending on same factors for normal scrollable frames.
Differential Revision: https://phabricator.services.mozilla.com/D125125
This frame property's type is small enough to fit directly in the property
table's 64-byte slot; so, this patch makes us store the data directly there
(rather than allocating it externally and storing a pointer in the table).
This patch shouldn't impact behavior at all.
Differential Revision: https://phabricator.services.mozilla.com/D126031
I have no idea how to make the test result stable because the intermittent
failure is caused by a race of `IMEContentObserver`'s content query performend
at vsync and `keypress` event after the `keydown` event. Therefore, I try to
fix the root cause of the failure.
There are two paths reaching a public method of editor with pending
notifications. One is `keypress` event listener of the editor. The other is
`execCommand` related methods of `Document`. Therefore, we should make them
flush pending notifications before accessing editor, but the cost may be too
expensive. So we should consider whether we should flush pending notifications
or not as far as later.
Note that we cannot fix the `beforeinput` cases because flushing pending
notifications after dispatching `beforeinput` event may cause oranges. It'll
be fixed while I'm working on bug 1710784.
Differential Revision: https://phabricator.services.mozilla.com/D125805
Currently, we assume any flex item with percentage padding will be
marked as dirty if the percentage basis is changed. However, it is not
true.
To fix it, we cache the flex item's border and padding used in its most
recent final reflow to detect their changes.
dynamic-isize-change-004.html is designed to catch the concern in bug
1700580 comment 12.
Differential Revision: https://phabricator.services.mozilla.com/D125620
This patch introduces a class that caches metrics in flex item's final
reflow. With it, we have a better symmetry for caches, one for measuring
reflow and the other for final reflow. Also, we don't have to explain
that mLastReflowTreatedBSizeAsIndefinite is only meaningful if
mFinalReflowSize is set.
Differential Revision: https://phabricator.services.mozilla.com/D124967
Add `CachedFlexItemData::Update()` with the same arguments as the
constructor to update the existing cache for both the measuring & final
reflow.
`mFinalReflowSize` is going to be renamed in a later patch, so I also
change `UpdateFinalReflowSize()` to `Update()` for consistency with the
new API.
Differential Revision: https://phabricator.services.mozilla.com/D124966
Similar to bug 1728319, a huge main gap size can also make SumOfGaps()
negative due to integer overflow. This patch is to recognize that
scenario.
We still need to annotate the crashtest because it still triggers the
following assertion in nsIFrame.
```
ASSERTION: inline-size less than zero: 'result >= 0'
```
Differential Revision: https://phabricator.services.mozilla.com/D125778
After the fixes in this patch, the REQUIRES_UNIFIED_BUILD declaration is no
longer needed, so I'm removing it here. This directory now builds successfully
with that removed and with ac_add_options --disable-unified-build in the
mozconfig.
Differential Revision: https://phabricator.services.mozilla.com/D125738
After the fixes in this patch, the REQUIRES_UNIFIED_BUILD declaration is no
longer needed, so I'm removing it here. This directory now builds successfully
with that removed and with ac_add_options --disable-unified-build in the
mozconfig.
Depends on D125610
Differential Revision: https://phabricator.services.mozilla.com/D125611
It turns out this assertion (added as part of bug 1725555) is not necessarily valid.
When we're updating the frame tree in response to DOM modifications (in the testcase
here, we're under nsCSSFrameConstructor::ContentRemoved), we may call DeleteFrom on
the primary textFrame first, which results in calling SetPrevInFlow(nullptr) on its
nextContinuation; this in turn clears the mFirstContinuation back-pointers in all
the successors. But if we then call DeleteFrom on one of the continuations later
in the chain, those nulled-out pointers trigger this assertion. In fact, it's OK
for them to be null in this case, so the assertion is over-zealous and we should
drop it.
I believe the only time it's OK for this to happen is if the chain of nsContinuingTextFrames
has been "detached" from the primary frame during frame-tree updating, as has happened in
this example.
We can still sanity-check the mFirstContinuation pointer here by asserting that it
matches the FirstContinuation() reported by our prev-continuation, or is null if there
is no prev-continuation. This is a bit expensive, though, so it's a only a debug-mode
assertion (for the fuzzers to try and hit).
Differential Revision: https://phabricator.services.mozilla.com/D125444
It turns out this assertion (added as part of bug 1725555) is not necessarily valid.
When we're updating the frame tree in response to DOM modifications (in the testcase
here, we're under nsCSSFrameConstructor::ContentRemoved), we may call DeleteFrom on
the primary textFrame first, which results in calling SetPrevInFlow(nullptr) on its
nextContinuation; this in turn clears the mFirstContinuation back-pointers in all
the successors. But if we then call DeleteFrom on one of the continuations later
in the chain, those nulled-out pointers trigger this assertion. In fact, it's OK
for them to be null in this case, so the assertion is over-zealous and we should
drop it.
I believe the only time it's OK for this to happen is if the chain of nsContinuingTextFrames
has been "detached" from the primary frame during frame-tree updating, as has happened in
this example.
We can still sanity-check the mFirstContinuation pointer here by asserting that it
matches the FirstContinuation() reported by our prev-continuation, or is null if there
is no prev-continuation. This is a bit expensive, though, so it's a only a debug-mode
assertion (for the fuzzers to try and hit).
Differential Revision: https://phabricator.services.mozilla.com/D125444
This should ensure the correct behavior when system colors are
semi-transparent, like on macOS on dark mode.
Testing this without hard-coding the system color seems hard (and I
think macOS on automation might not even hard native dark mode support
anyways).
In fact, if it did I think backplat-bg-image-006 would've caught it.
Differential Revision: https://phabricator.services.mozilla.com/D125475
WebRender prefers to know the full bounds of the primitive, since it makes invalidation easier (and doesn't increase the size of the commands we send).
Differential Revision: https://phabricator.services.mozilla.com/D124588
WebRender prefers to know the full bounds of the primitive, since it makes invalidation easier (and doesn't increase the size of the commands we send).
Differential Revision: https://phabricator.services.mozilla.com/D124588
A UAX29 compatible word breaker (like ICU4C) treat the end of text as a
word break opportunity (rule WB2 [1]), but currently lwbrk word breaker
doesn't.
The motivation of this patch is to make `WordBreaker::Next()` closer to
a UAX29 compatible one (at least for English text), and see if the
callers need to change. This should make the future integration of ICU4X
segmenter easier.
The only caller of WordBreaker::Next() is ClusterIterator's constructor.
This patch shouldn't change its behavior because we've already manually
assigned a word break point at the end of the line when `aContext` is
empty and `aDirection` is -1. This patch generalizes it to all
conditions.
Also, update TestPrintWordWithBreak() so that the result string makes
more sense.
[1] https://www.unicode.org/reports/tr29/#WB2
Differential Revision: https://phabricator.services.mozilla.com/D124304
It's interesting case, and it perhaps should be tested in WPT for web-compat.
Chrome 93 passes all tests in the new WPTs, but Gecko fails in the cases of
related to focus (i.e., `execCommand` and user input).
Differential Revision: https://phabricator.services.mozilla.com/D124725
WebRender prefers to know the full bounds of the primitive, since it makes invalidation easier (and doesn't increase the size of the commands we send).
Differential Revision: https://phabricator.services.mozilla.com/D124588
WebRender prefers to know the full bounds of the primitive, since it makes invalidation easier (and doesn't increase the size of the commands we send).
Differential Revision: https://phabricator.services.mozilla.com/D124588
We could fix the testcase in this patch by promoting
`FlexLine::mTotalItemMBP` to `AuCoord64`, but then
`layout/generic/crashtests/1488762-1.html` will start crashing. It is
because `FlexItem::OuterMainSize()` can return negative size due to
integer overflow, and the negative sizes will accumulate in
`mTotalOuterHypotheticalMainSize`.
Instead of promoting more variables to `AuCoord64` to workaround huge
margin/border/padding that we cannot handle gracefully, this patch
tweaks the assertion to check only if `mTotalOuterHypotheticalMainSize`
and `mTotalItemMBP` have valid values.
Differential Revision: https://phabricator.services.mozilla.com/D124409
Also, more directly go from StyleImageRendering to wr::ImageRendering.
* image-rendering: smooth the non-deprecated version of
OptimizeQuality, which maps to SamplingFilter::LINEAR /
wr::ImageRendering::Auto (which uses gl::LINEAR).
* image-rendering: pixelated maps to wr::ImageRendering::Pixelated /
SamplingFilter::POINT which is the same crisp-edges does.
Note that this uncovers that we were mapping image-rendering:
crisp-edges to wr::ImageRendering::Pixelated.
I'm going to preserve behavior on this patch but we should consider
switching that to map to wr::ImageRendering::CrispEdges on a
follow-up (filed bug 1728831 for this).
Differential Revision: https://phabricator.services.mozilla.com/D124378
Not sure we even need this anymore but just doing this so I can finish the fission audit.
Added way back in bug 588407.
This shouldn't actually be any behaviour change: anything that is IsRootContentDocumentInProcess but not IsRootContentDocumentCrossProcess should be a oop if with fission (unless I'm missing a case), so we will never hit this code path, we'll hit the remote iframe path above.
Differential Revision: https://phabricator.services.mozilla.com/D124277
Also, more directly go from StyleImageRendering to wr::ImageRendering.
* image-rendering: smooth the non-deprecated version of
OptimizeQuality, which maps to SamplingFilter::LINEAR /
wr::ImageRendering::Auto (which uses gl::LINEAR).
* image-rendering: pixelated maps to wr::ImageRendering::Pixelated /
SamplingFilter::POINT which is the same crisp-edges does.
Note that this uncovers that we were mapping image-rendering:
crisp-edges to wr::ImageRendering::Pixelated.
I'm going to preserve behavior on this patch but we should consider
switching that to map to wr::ImageRendering::CrispEdges on a
follow-up (filed bug 1728831 for this).
Differential Revision: https://phabricator.services.mozilla.com/D124378
Disabled by default, browser.places.interactions.enabled, this adds scrolling metrics (time spent scrolling and distance scrolled) to the history metadata.
Differential Revision: https://phabricator.services.mozilla.com/D120656
This code clearly only wants to handle the case where there is zooming and the scrollbar sizes have a bound (screen size or maximum window size from OS).
Differential Revision: https://phabricator.services.mozilla.com/D124284
This has to do with determining whether visual or layout coords are used, which is determined by the cross process root content doc.
Differential Revision: https://phabricator.services.mozilla.com/D124283
We use it to determine if we had applied resolution that we need to remove, that is only done at the cross process root content document, not an in process root content document.
As a confirmation of this, the function we get the rect from, CalculateCompositionSizeForFrame, also uses IsRootContentDocumentCrossProcess to determine if the rect is handled specially.
Differential Revision: https://phabricator.services.mozilla.com/D124253
Ting-Yu Lin
Nika Layzell
Andrew Osmond
Hiroyuki Ikezoe
Csoregi Natalia
Masayuki Nakano
Mike Hommey
Jonathan Kew
Boris Chiou
Dan Minor
Miko Mynttinen
Butkovits Atila
Emilio Cobos Álvarez
Noemi Erli
Sandor Molnar
Greg Tatum
Chris Peterson
Marian-Vasile Laza
Andi-Bogdan Postelnicu
Sean Feng
Cristian Tuns
Daniel Holbert
Iulian Moraru
Evgenia Kotovich
criss
Norisz Fay
Jeff Muizelaar
Alexandru Michis
Timothy Nikkel
Eitan Isaacson
Narcis Beleuzu
Andi-Bogdan Postelnicu
Emily McDonough
Morgan Reschenberg
Tetsuharu Ohzeki
Stephen A Pohl
James Teh
Matt Woodrow
Mats Palmgren
Cosmin Sabou
Andrew Creskey
Michelle Goossens