Having two classes in the inheritance chain inherit from SupportsWeakPtr
now won't compile, but you can use WeakPtr<Derived> when any base class
inherits from SupportsWeakPtr.
Differential Revision: https://phabricator.services.mozilla.com/D83674
This patch basically attempts to make clicking in the scrollbar track outside of the scrollthumb "work". Clicking in the scrollbar track usually does a page scroll via nsSliderFrame::PageScroll. This eventually ends up in ScrollFrameHelper::ScrollBy where we turn the request from a relative one ("scroll by a page") into an absolute one ("scroll to this position").
This page scroll is typically a smooth scroll and is currently done on the main thread/layout side. Once we start scrolling the visual viewport offset with the scrollbars we can no longer do this purely on the layout side, we at least need the help of the compositor side. I think the simplest way to do this is to hand the scroll request off to the compositor and have it handle the whole thing.
Now we need to consider the following situation: user clicks scrollbar track to page scroll, smooth scroll gets partway complete on the compositor, user clicks again on scrollbar track for a further page scroll. The main thread can't send an absolute scroll offset update request to the compositor at this point because it has outdated information (it needs a 'starting position' to add the page scroll offset amount) so it'll end up scrolling to the wrong place. It has to send a relative scroll offset update.
We already have a mechanism to send relative scroll offset updates. It is implemented by sending a base scroll offset and the desired scroll offset, and then on the compositor send the difference between those two is computed and then added to the scroll offset.
This patch creates a new mechanism (so called "pure relative") that just sends a relative offset update without any absolute scroll positions. The reason I did this is because the existing relative scroll offset update mechanism is not aware of visual viewport offsets, but rather only layout scroll position. For example, here
https://searchfox.org/mozilla-central/rev/8d55e18875b89cdf2a22a7cba60dc40999c18356/layout/generic/nsGfxScrollFrame.h#446
the value we use for the base scroll offset (mApzScrollPos) is set to the layout scroll position. It may be entirely reasonable to make this existing mechanism vv offset aware, but I wanted to implement something to get it working with a smaller chance of regressions to things that already exist and work. Ideally these two mechanims would be merged.
Differential Revision: https://phabricator.services.mozilla.com/D82688
This offset was reset in one of the two codepaths of D80723, but turns
out it's important for same-origin documents that are also
root-content-documents, like about: pages in the parent process, which
happened to hit the codepath that did _not_ reset it. :(
Differential Revision: https://phabricator.services.mozilla.com/D84584
This makes its ownership a bit clearer - it's now encoded in the type system
that nsPageSequenceFrame is the owner of this object, and we can reason about
the implications of that for the other frames that retain a pointer to this
object. (Fortunately all those other frames will be destroyed before the
nsPageSequenceFrame that owns their nsSharedPageData, because they're
descendants of that frame.)
Differential Revision: https://phabricator.services.mozilla.com/D84463
It seems win7 sometimes displaces it slightly. We've hit this in the
past and it's not the point of the test so just get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D84597
Before my patches the background images in table-background-print didn't
seem to load on time.
I tried to make the images* tests non-fuzzy, but the <svg:image> really
ruined the deal. A bit of a shame that they fall into a subpixel
boundary because of page margins. So allow a bit of fuzz there rather
than spending another few days trying :)
Differential Revision: https://phabricator.services.mozilla.com/D84516
We need to set the original document ASAP so images triggered from the
clone use the right service worker.
It is a bit unfortunate to have the static document checks twice, but we
may get to Document::GetClientInfo before the cloned doc has a window,
so it's not 100% clear to me how we could avoid it.
Differential Revision: https://phabricator.services.mozilla.com/D82081
Otherwise my test fails intermittently on CI. We need to block on all
the load blockers because stuff like responsive images doesn't fire the
load directly but they do that as a micro task (blocking the load
event).
Differential Revision: https://phabricator.services.mozilla.com/D81989
Make them perform the image load (if needed), instead of copying the
image requests from the original document.
This is needed for CSS for stuff like:
@media print {
#foo::before {
content: url(bar.png);
}
}
And so on. For images, we should do this as well. Nothing prevents you
from doing:
<picture>
<source srcset="print.png" media="print">
<source srcset="screen.png" media="not print">
<img>
</picture>
And that should in theory work. It works after this patch, and I added a
test for that.
This patch is a bit bigger than I'd like, but I didn't find a more
reasonable way to split it up.
Making static docs able to do image loads is most of the patch and is
mostly straight-forward. This allows to remove the hacky "change the
loading document" thing that CSS images do, which is just working around
the CSP of the print document.
I need to enable background colors in printpreview_helper so as to be
able to have a reference page for all the different image types.
Differential Revision: https://phabricator.services.mozilla.com/D81779
This changes the UA widget setup (again). What is going on in this
test-case is that we have a marquee inside a video, two things that have
their own UA widget. Given how the code is currently written, the
runnable to attach and set up the marquee's widget is posted before than
the video one (which is potentially reasonable).
However that means that the marquee one runs before and flushes layout,
and catches the video in an inconsistent state (in the composed doc, but
without a shadow root). That in turn messes up reflow because
nsVideoFrame assumes stuff.
Rather than putting the attach / detach logic in script runners, just
run that bit synchronously, and post only the event async. I audited the
consumers of those events and it seems fine to me, they either already
deal with the possibility of the shadow root being already detached or
they don't care.
For teardown, none of the destructors of the UA widgets rely on the
shadow root being still attached to the element.
Differential Revision: https://phabricator.services.mozilla.com/D84487
Before my patches the background images in table-background-print didn't
seem to load on time.
I tried to make the images* tests non-fuzzy, but the <svg:image> really
ruined the deal. A bit of a shame that they fall into a subpixel
boundary because of page margins. So allow a bit of fuzz there rather
than spending another few days trying :)
Differential Revision: https://phabricator.services.mozilla.com/D84516
We need to set the original document ASAP so images triggered from the
clone use the right service worker.
It is a bit unfortunate to have the static document checks twice, but we
may get to Document::GetClientInfo before the cloned doc has a window,
so it's not 100% clear to me how we could avoid it.
Differential Revision: https://phabricator.services.mozilla.com/D82081
Otherwise my test fails intermittently on CI. We need to block on all
the load blockers because stuff like responsive images doesn't fire the
load directly but they do that as a micro task (blocking the load
event).
Differential Revision: https://phabricator.services.mozilla.com/D81989
Make them perform the image load (if needed), instead of copying the
image requests from the original document.
This is needed for CSS for stuff like:
@media print {
#foo::before {
content: url(bar.png);
}
}
And so on. For images, we should do this as well. Nothing prevents you
from doing:
<picture>
<source srcset="print.png" media="print">
<source srcset="screen.png" media="not print">
<img>
</picture>
And that should in theory work. It works after this patch, and I added a
test for that.
This patch is a bit bigger than I'd like, but I didn't find a more
reasonable way to split it up.
Making static docs able to do image loads is most of the patch and is
mostly straight-forward. This allows to remove the hacky "change the
loading document" thing that CSS images do, which is just working around
the CSP of the print document.
I need to enable background colors in printpreview_helper so as to be
able to have a reference page for all the different image types.
Differential Revision: https://phabricator.services.mozilla.com/D81779
I had needed this before to export that header, and it's no longer
needed, but it seems useful anyways.
Depends on D81989
Differential Revision: https://phabricator.services.mozilla.com/D84252
As per the following change to the spec:
6b3d7240b5
The additional failure annotation is added because we don't currently treat
text-combine-upright as non-animatable and this patch exposes the existing bug
(bug 1654195).
Differential Revision: https://phabricator.services.mozilla.com/D84308
We do not expose it nor ever style it. Just use the parent style all the
time. This avoids problematic style resolution calls during reflow.
Differential Revision: https://phabricator.services.mozilla.com/D84358
On WebRender there is no layer tree structures so that we can't accumulate
transform values up to the nearest APZ's scroll layer by walking up the layer
tree, or we can't tell a given transform animation is inside a perspective layer
to decide whether we need to apply the offset from the reference frame or not
[1]. So we get the accumulated transform by using
nsLayoutUtils::GetTransformToAncestor on the main-thread and inform it to the
compositor thread, and also inform the offset which is set conditionally [2]
so that we don't need to tell whether the transform animation is inside a
perspective layer or not on the compositor thread.
I am not yet 100% sure that these values are same both on WebRender and non
WebRender in all cases, once after partial pre-rendering transforms have
been used in the wild well enough and any problem has not appeared, even if
there are problems we should fix them then the non WebRender version should
eventually use this same setup instead of walking up the layer tree.
[1] https://searchfox.org/mozilla-central/rev/85ae3b911d5fcabd38ef315725df32e25edef83b/gfx/layers/CompositorAnimationStorage.cpp#273-275
[2] https://searchfox.org/mozilla-central/rev/85ae3b911d5fcabd38ef315725df32e25edef83b/layout/painting/nsDisplayList.cpp#7879-7891
Differential Revision: https://phabricator.services.mozilla.com/D83201
This is a test case which will fail if we didn't factor the position of the
transform from the reference frame in the jank mechanism in cases where the
transform is inside a perspective layer. In the case of non WebRender, we've
already factored it in FrameTransformToTransformInDevice() [1].
For WebRender we will need to factor it in a different way becase there is no
layer tree structures so that we can't tell whether the transform is inside
a perspective layer or not by looking at the parent layer.
Note that, as of now, this test doesn't fail on WebRender since there is no jank
mechanism on WebRender yet.
[1] https://searchfox.org/mozilla-central/rev/7ec7ee4a9bde171ba195ab46ed6077e4baaef34d/gfx/layers/CompositorAnimationStorage.cpp#276-282
Differential Revision: https://phabricator.services.mozilla.com/D83200
nsPreContext::mDynamicToolbarHeight is representing the state of the dynamic
toolbar in transition or is being collapsed. So if we leave the value as it is,
we misrecognize the state, the visual viewport width/height are significantly
affected by the misrecognition, it returns 0 because in the collapsed or the
transition state, it returns the special value [1] which is never properly set
without calling nsPresContext::UpdateDynamicToolbarOffset.
This mismatching state doesn't much matter in the real sites since we don't
often change the max height of the dynamic toolbar but in automated tests it's
a big problem. In fact a test case which will be introduced in the next commit
will not work properly without this fix.
[1] https://searchfox.org/mozilla-central/rev/1b95a0179507a4dc7d4b0c94c2df420dc1a72885/dom/base/VisualViewport.cpp#78
Differential Revision: https://phabricator.services.mozilla.com/D83902
The gist of this patch is: once the feasible and infeasible block-size
is within one device pixel, we choose nextGuess to be the greatest
multiple of one device pixel below or equal to the feasible block-size.
If this nextGuess is infeasible, we will reflow children one last time
by using the last feasible block-size and done with the balancing.
Differential Revision: https://phabricator.services.mozilla.com/D83732
Here's an example that can break the loop at the first iteration.
<div style="column-count:2; height:100px"><img src="" style="height:500px">
Differential Revision: https://phabricator.services.mozilla.com/D83731
Without setting font and line-height, these reftests may yield different
results on different platforms because of the default font are
different. Also, their optimal column balancing height may not be an
integer in CSS pixels.
I discover this because they are failing due to 1px column height
difference after we stop searching optimal balancing height within a
certain threshold on either macOS, Windows, or Android.
Differential Revision: https://phabricator.services.mozilla.com/D83730
* floats-clear-multicol-balancing-*:
Change border-width from "normal" to "5px" so that the optimal column
height is 85px. This also makes those reftests renders the same across
all browsers since each browser renders "normal" differently.
* column-balancing-overflow-005:
This test is already wrong as its height is 13px/3 = 4.3333px, so it can
pass with some fuzzy. This patch makes the target column height
4px (including the children's overflow). This is the same as the `<p>`'s
height 4px in reference file.
* box-decoration-break-border-image:
Add 1px to .vbreak so that the optimal column balancing height is a
integer. Also, remove a whitespace between two `<span>` in `<pos2>` to make the
test more robust because the width of the whitespace is not an integer.
Differential Revision: https://phabricator.services.mozilla.com/D83729
The combined overflow area has been split into ink and scrollable
overflow areas in bug 542595. Drop the sentence related to it, and
update the old comment.
Differential Revision: https://phabricator.services.mozilla.com/D84232
Brad Werth
Erik Nordin
Olli Pettay
tkhan
Emilio Cobos Álvarez
Timothy Nikkel
Jonathan Watt
Narcis Beleuzu
Daniel Holbert
Kagami Sascha Rosylight
Alexander Surkov
Jonathan Kew
Brian Birtles
Mats Palmgren
Cosmin Sabou
Simon Giesecke
Hiroyuki Ikezoe
Ting-Yu Lin