The previous code tried to do it, but it did it wrongly, as the overflow clip
comes from the parent, not the child.
Thus when we change a style that influences it, we weren't invalidating the
SIMPLE_DISPLAY_LIST bit, and such.
Make the reftest that caught this fail more reliable.
Differential Revision: https://phabricator.services.mozilla.com/D51805
--HG--
extra : moz-landing-system : lando
This fixes css/css-contain/contain-paint-{002,012,024}.html when not using the
fast path (i.e., with the following patch).
Also invert the check in IsStackingContext as IsFrameOfType is a virtual method,
and IsContain* is just a bitflag.
Differential Revision: https://phabricator.services.mozilla.com/D51804
--HG--
extra : moz-landing-system : lando
Update the comments, name, and fields to show it is agnostic of isize/bsize.
Differential Revision: https://phabricator.services.mozilla.com/D51739
--HG--
extra : moz-landing-system : lando
Now that there is no Gecko-contributed background color in the window any more,
there's nothing that needs to be cleared away. This simplifies things.
Differential Revision: https://phabricator.services.mozilla.com/D51464
--HG--
extra : moz-landing-system : lando
For regular elements, whenever -moz-appearance is used, the CSS background is
ignored. Root elements were behaving specially, and the background color also
needed to be adjusted.
For example, for Windows 7, we have the following CSS rule;
```
:root {
background-color: transparent;
-moz-appearance: -moz-win-borderless-glass;
}
```
This change makes the root element more consistent with other elements, so the
extra `background-color: transparent` declaration is no longer necessary.
This change does not let content documents opt out of forced opaqueness:
Root content documents still get an opaque background color from an existing
check further down in this method.
Differential Revision: https://phabricator.services.mozilla.com/D51459
--HG--
extra : moz-landing-system : lando
Accept assertions to avoid intermittent test failures due to assertion count mismatches.
Differential Revision: https://phabricator.services.mozilla.com/D50660
--HG--
extra : moz-landing-system : lando
This distinguishes better between the overloaded aspect of the PerFrameKey and the
actual mixed value.
Depends on D37803
Differential Revision: https://phabricator.services.mozilla.com/D37804
--HG--
extra : moz-landing-system : lando
This static method is assumed to have the same signature as the type's constructor,
and so we must have an implementation of ComputePerFrameKey for each constructor
a display item provides that is called by MakeDisplayItem. Notably this excludes
the MakeClone constructor for a lot of items.
There is a default varargs implementation on nsDisplayItem which everyone
inherits by default, so types which previously didn't overload this method
still don't need to.
Providing an implementation of ComputePerFrameKey on some display item type
shadows the varargs implementation, so one doesn't need to worry about overloading
one constructor but forgetting about another -- if you do, the compiler will only
see the overload and complain that the signature doesn't match.
One slightly annoying result of this is that display items which previously
inherited an overloaded implementation from a superclass now must provide
their own manual implementations. Although as far as I could tell, all of
those cases had a trivial implementation of key=0 (the super class supported
custom keys but the subclasses didn't make use of it).
In those cases I just hardcoded key=0, but it's possible that it would be
better to call into the superclass' implementation to be more robust to changes.
Differential Revision: https://phabricator.services.mozilla.com/D37803
--HG--
extra : moz-landing-system : lando
Add test annotations to the ReftestManifest and TestResolver. For example, a
test description from the TestResolver might now contain 'skip-if': 'skiaContent';
similar to the content provided for manifestparser tests; this will allow
'mach test-info report' to filter tests based on reftest manifest test
annotations.
Also add the referenced-test field which identifies the test file associated
with test entries for reference files; this will allow test-verify to
run the correct reftest when only the reference file has been modified.
Differential Revision: https://phabricator.services.mozilla.com/D51113
--HG--
extra : moz-landing-system : lando
The glyph pixel space in which we rasterized glyphs differed from how we
rendered the rasterized glyphs in the shader. They need to be in
agreement because the glyph subpixel offset selected during
rasterization depends on it. This patch should make the paths consistent
with each other.
Additionally, during animations, we now snap the reference frame
relative offset ignoring the impact of any animated transforms. This
helps with minimizing glyph wiggling during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D51305
--HG--
extra : moz-landing-system : lando
When blobs were lazily rasterized it was relatively cheap to create very large blob layers. Now that we move to pre-rasetrizing all blob tiles during scene building, large blob layers cause excessive memory allocation and CPU usage.
Differential Revision: https://phabricator.services.mozilla.com/D51576
--HG--
extra : moz-landing-system : lando
This way we get the correct values for start-up prefs in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D51061
--HG--
extra : moz-landing-system : lando
A speculative fix for intermittent android reftest failures in which the reftest log file
is incomplete but the missing logging is found in the logcat: I hope that closing the
log file explicitly will ensure logging is flushed before the application quits.
Differential Revision: https://phabricator.services.mozilla.com/D51695
--HG--
extra : moz-landing-system : lando
Some crashtests call window.location.reload one or more times. Each time the test document loads we call OnDocumentLoad, and each call of that function can lead to a RecordResult call, either directly or indirectly through WaitForTestEnd and its MakeProgress state machine.
Although the error when this happens ("program error managing timeouts") is confusing I found a couple intermittent instances of this happening in our bugzilla.
However with the fission changes to the reftest harness (which in general make things more async) this is much more common because we keep the tests alive longer before tearing down the test page, giving it more of a chance to happen.
To fix it we pass around the top level test url so it can make its way to RecordResult. This means we can ignore RecordResult calls for previous tests, and ignore the second or more RecordResult call for the current test. We reset the count when we start a new test.
Differential Revision: https://phabricator.services.mozilla.com/D51342
--HG--
extra : moz-landing-system : lando
nsPrintData::mBrandName never changes over the lifetime of a Firefox instance.
It is wasteful to have nsPrintData obtain and store it, since we can replace
an nsPrintJob's nsPrintData object multiple times over the lifetime of the
nsPrintJob and nsPrintJob is the only consumer.
Differential Revision: https://phabricator.services.mozilla.com/D51689
--HG--
extra : moz-landing-system : lando
The previous code tried to do it, but it did it wrongly, as the overflow clip
comes from the parent, not the child.
Thus when we change a style that influences it, we weren't invalidating the
SIMPLE_DISPLAY_LIST bit, and such.
Make the reftest that caught this fail more reliable.
Differential Revision: https://phabricator.services.mozilla.com/D51683
--HG--
extra : moz-landing-system : lando
Spoof dom/dom.properties, layout/xmlparser.properties,
layout/MediaDocument.properties to en-US if needed.
Differential Revision: https://phabricator.services.mozilla.com/D46034
--HG--
extra : moz-landing-system : lando
Spoof dom/dom.properties, layout/xmlparser.properties,
layout/MediaDocument.properties to en-US if needed.
Differential Revision: https://phabricator.services.mozilla.com/D46034
--HG--
extra : moz-landing-system : lando
Currently, "input" event is fired when the `AutoScriptBlocker` in `SetValue()`
is deleted. So, for keeping same behavior, the post processing after calling
`TextEditor` methods should be done before editor dispatches "input" event.
Fortunately, `TextInputListener::OnEditActionHandled()` is a good chance to
do that. Therefore, this patch makes it notify `TextControlState` and
`AutoTextControlHandlingState`.
Note that ideally, each method of `TextEditor` should return
`NS_ERROR_OUT_OF_MEMORY` coming from
`AutoTextControlHandlingState::OnEditActionHandled()`. However, it requires
a lot of changes in editor classes, and the case is really rare since editor
does not use fallible allocation. Therefore, it must be okay to crash in
editor if `OnEditActionHandled()` returns `NS_ERROR_OUT_OF_MEMORY`.
Depends on D51395
Differential Revision: https://phabricator.services.mozilla.com/D51396
--HG--
extra : moz-landing-system : lando
It should be in `mozilla` namespace and it manages not only `TextEditor`,
manages selection, selection controller and callback from editor. so that
I think it stores state of "text control widget". Therefore, I name it to
`TextControlState`.
And cleaning up the cpp file.
Differential Revision: https://phabricator.services.mozilla.com/D51391
--HG--
rename : dom/html/nsTextEditorState.cpp => dom/html/TextControlState.cpp
rename : dom/html/nsTextEditorState.h => dom/html/TextControlState.h
extra : moz-landing-system : lando
Previously, WR needed to update and track dependencies for all
allocated picture cache tiles in the virtual display port. This
means doing extra CPU work (dependency updates) and in some cases,
extra GPU work (larger off-screen child surfaces) than are strictly
required.
With this patch, each tile determines if it is currently visible in
pre_update. If the tile isn't visible, we skip doing dependency
updates until it is on screen again. More importantly, this is
used to reduce the world culling rect for primitive preparation,
which also means large child surfaces only require allocations
large enough to enclose the visible tiles, rather than the
display port.
Differential Revision: https://phabricator.services.mozilla.com/D51006
--HG--
extra : moz-landing-system : lando
Split off of Bug 1590894
Rename these to support unprefixed version
Also add alias to keep compatibility
Differential Revision: https://phabricator.services.mozilla.com/D50989
--HG--
extra : moz-landing-system : lando
In common cases where the caret is in a position:static frame subtree,
the caret's position (relative to canvas frame's custom content
container) should not be changed during scrolling.
However, when the caret is in a position:fixed or "stuck"
position:sticky frame subtree, the caret's position will change during
scrolling. We need to disable APZ to avoid jumpy carets.
Differential Revision: https://phabricator.services.mozilla.com/D51351
--HG--
extra : moz-landing-system : lando
This is the main patch to fix bug 1526268.
It is wrong to use the cached rects relative to the root
frame (ViewportFrame) to detect whether AccessibleCaret's position is
changed or not, because it doesn't account the root scroll frame's
scroll offset.
The effect is that we always produce "PositionChangedResult::Changed"
when scrolling on position:static elements, but
"PositionChangedResult::NotChanged" on position:fixed elements.
This patch fixes this by using the rect relative to custom content
container, which is the actually rect to set caret's position, to check
whether the position is changed or not.
Note that even with this patch, the caret on "position:fixed" element is
still jumpy during scrolling due to APZ. Part 3 will fixed this.
Differential Revision: https://phabricator.services.mozilla.com/D51350
--HG--
extra : moz-landing-system : lando
The #text-overlay and #image child divs were "position: absolute" under
the main AccessibleCaret div. However, they don't necessary need to be
position:absolute to achieve the desired layout. We can make them normal
in-flow elements to simplify the frame structure. There should not be
any perceivable change to the user.
Also, AccessibleCaret's position can made more accurate by using float
CSS pixels when converting it from app unit.
Differential Revision: https://phabricator.services.mozilla.com/D51349
--HG--
extra : moz-landing-system : lando
This is not an error in the same way as a download failure, and should not be reported as one.
An Info message is sufficient.
Also suppress "unknown" location in messages about @font-face rules, as it is not useful,
pending a proper fix (bug 1450903).
Differential Revision: https://phabricator.services.mozilla.com/D50346
--HG--
extra : moz-landing-system : lando
Lots of these callbacks have a non-`void*` final parameter, which UBSAN
complains about. This commit changes them to have a `void*` parameter.
This requires undoing the machinery added in the first two commits of bug
1473631: `TypePrefChangeFunc` and `PREF_CHANGE_METHOD`. The resulting code is
simpler (which is good) and more boilerplate-y (which is bad) but avoids the
undefined behaviour (which is good).
Differential Revision: https://phabricator.services.mozilla.com/D50901
--HG--
extra : moz-landing-system : lando
We cache the path in AnimationInfo for layers, and in
CompsoitorAnimationStorage for web-renderer.
Differential Revision: https://phabricator.services.mozilla.com/D50013
--HG--
extra : moz-landing-system : lando
This also includes the implementation of SetAnimatable, FromAnimatable,
and merge the final matrix with motion path.
Besides, we always use PathBuilderSkia for calculating the gfx::Path for
web-renderer.
Differential Revision: https://phabricator.services.mozilla.com/D50011
--HG--
extra : moz-landing-system : lando
We need to pass these two types into the compositor, so we need a better
way to serialize these rust types. We use serde and bincode to
serialize/deserialize them, and use ByteBuf to pass the &[u8] data
through IPC. We define StyleVecU8 for FFI usage only.
Differential Revision: https://phabricator.services.mozilla.com/D50688
--HG--
extra : moz-landing-system : lando
On the compositor thread in GPU process (i.e. web-renderer), gfxPlatform() is
not initialized, so we don't have the DrawTarget information.
Fortunately, all we need is to calculate the motion point and direction
vector, so we don't have to care about which backend we use.
Therefore, make PathBuilder as a parameter, so we can just pass a valid
PathBuilder on the compositor thread. For main thread (i.e. content
process), using the original way is fine.
Differential Revision: https://phabricator.services.mozilla.com/D50010
--HG--
extra : moz-landing-system : lando
The current implementation uses nsIFrame to get everything. However, we
want to reuse ResolveMotionPath() on the compositor thread (in the parent
process), so we need to refactor this function to avoid using nsIframe
everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D50009
--HG--
extra : moz-landing-system : lando
I'd like to add some new data type for motion path, so it'd be great to
put all of them in an independent file.
Differential Revision: https://phabricator.services.mozilla.com/D50008
--HG--
extra : moz-landing-system : lando
