The distinction is not exposed at the JS level which currently always uses
"restore", but it could be if necessary.
Differential Revision: https://phabricator.services.mozilla.com/D16346
--HG--
extra : moz-landing-system : lando
The tests for Bug 1133905 all compare the visibility of scrollbars with
differently-sized css viewports. This patch has some affect on the
viewport sizing that I don't understand, and it causes some of the tests
to start passing and some to start failing.
The test for Bug 1242172 has elements sized to height 100% and checking
for the presence or absence of scrollbars. In this case the patch appears
to increase the css viewport height and decrease the width -- again for
reasons I don't understand -- and this affects the scrollbar sizes.
Differential Revision: https://phabricator.services.mozilla.com/D16078
--HG--
extra : moz-landing-system : lando
The added crashtest still crashes on Android verify runs (TV) for
unknown reasons, so skip it.
Differential Revision: https://phabricator.services.mozilla.com/D16395
--HG--
extra : moz-landing-system : lando
We are using the unrounded dest rect to calculate the image decode size
in ComputeImageContainerDrawingParameters, while passing the rounded
dest rect to WebRender. This mismatch causes images to be decoded to one
size and display at another, cause some visual distortions. Using the
correct rect seems to allow us to remove the extra snapping logic added
to work around this.
At this time, how we snap is different between WebRender and
non-WebRender in general. This patch will likely morph again once we
bring the two models closer together.
Differential Revision: https://phabricator.services.mozilla.com/D15739
We only ever add a single sheet (EditorOverride.css) there anyway.
Depends on D16282
Differential Revision: https://phabricator.services.mozilla.com/D16283
--HG--
extra : moz-landing-system : lando
Based on https://bugzilla.mozilla.org/show_bug.cgi?id=1348519#c6 and
https://github.com/w3c/csswg-drafts/issues/3201:
Currently grid-template-rows/columns interpolate “per computed value”, which
means that if the number of tracks differs, or any track changes to/from a
particular keyword value to any other value, or if a line name is added/removed
at any position, the entire track listing is interpolated as “discrete”.
But we "agree" with two more granular options:
1. Check interpolation type per track, rather than for the entire list, before
falling back to discrete. I.e. a length-percentage track can animate between
two values while an adjacent auto track flips discretely to min-content.
2. Allow discrete interpolation of line name changes independently of track
sizes.
Besides, for the repeat() function, it's complicated to support interpolation
between different repeat types (i.e. auto-fill, auto-fit) and different repeat
counts, so we always fall-back to discrete if the first parameter of repeat()
is different.
Depends on D16339
Differential Revision: https://phabricator.services.mozilla.com/D16129
--HG--
extra : moz-landing-system : lando
WebRender can handle small image without much overhead. Allowing
small images will give us more predictable behaviour because
we don't end up merging things unneccessarily.
Differential Revision: https://phabricator.services.mozilla.com/D16337
--HG--
extra : moz-landing-system : lando
So that the caller doesn't have to retrieve and compare the previous viewport
offset himself.
Differential Revision: https://phabricator.services.mozilla.com/D15785
--HG--
extra : moz-landing-system : lando
During a "first paint" transaction, compositor-side state such as APZ's copy
of the visual viewport offset is overwritten. However, the scroll frame may
persist on the main thread, and in such a case we want to restore the visual
viewport offset stored in the scroll frame. This comes into play during e.g.
navigation back to a page.
Differential Revision: https://phabricator.services.mozilla.com/D16238
--HG--
extra : moz-landing-system : lando
This patch makes ContentIteratorBase, PostContentIterator, PreContentIterator
and ContentSubtreeIterator classes non-refcountable because most users can
create their instances in stack and such users may be in a hot path. So,
we can save a lot of cost of instantiation.
Unfortunately, only ScriptableContentIterator creates one of the concrete
classes and needs to destroy it properly. Therefore, its
EnsureContentIterator(), destructor, traverse and unlink code becomes messy.
However, ScriptableContentIterator was designed for automated tests and we
need to maintain it not so many times. Therefore, improvement of other
users must be worthwhiler than this demerit.
Differential Revision: https://phabricator.services.mozilla.com/D15928
--HG--
extra : moz-landing-system : lando
Now, nobody requires nsIContentIterator interface. So, we can get rid of it.
Unfortunately, there is no macro to keep the inherited class,
ContentSubtreeIterator, in the cycle collection to make it keep managing
ContentSubtreeIterator::mRange without nsISupports interface. Therefore, this
patch moves it into ContentIteratorBase temporarily. Anyway, the following
patch makes those classes not refcountable. At that time, this issue will be
fixed.
Differential Revision: https://phabricator.services.mozilla.com/D15927
--HG--
extra : moz-landing-system : lando
Now, all users of ContentSubtreeIterator can access it directly. This patch
makes them use the concrete class directly.
Differential Revision: https://phabricator.services.mozilla.com/D15920
--HG--
extra : moz-landing-system : lando
This mouse click seems superfluous, as window.focus() is called immediately after.
In addition, this click is somehow causing a page up scroll, as it's clicking
a slider frame. This causes the test to fail with scroll anchoring enabled,
for some reason. Removing this click seems to be the easiest solution, as it
doesn't seem intentional.
Differential Revision: https://phabricator.services.mozilla.com/D16276
--HG--
extra : rebase_source : 6e41d587e54d083b0930173d12db1fc180ae70fa
extra : histedit_source : a604e48df440974b7554b6ee8be01641abd92a64
Collapsing thumb causes frame of scrollbar to cache an incorrect pref
size, which makes it not able to appear in certain cases.
This patch changes it to use "visibility: hidden" instead so that the
thumb is hidden but still contributes to the width of scrollbar.
An alternative would be also change the code in nsScrollbarFrame to set
something other than collapsed attribute instead, but I'm not sure
whether doing that is any better than just adding a rule. We need the
rule anyway regardless of what we set on the element.
Differential Revision: https://phabricator.services.mozilla.com/D15244
--HG--
extra : moz-landing-system : lando
This fixes a bug that my previous patch uncovers, and that's tested by
css/css-masking/clip/clip-filter-order.html.
We weren't setting up the clips in a way that the clip property clipped filters
and such. This test works in Gecko because Gecko won't draw outside of the
effect bounds, that account for clip().
Differential Revision: https://phabricator.services.mozilla.com/D16232
This patch makes ContentIteratorBase, PostContentIterator, PreContentIterator
and ContentSubtreeIterator classes non-refcountable because most users can
create their instances in stack and such users may be in a hot path. So,
we can save a lot of cost of instantiation.
Unfortunately, only ScriptableContentIterator creates one of the concrete
classes and needs to destroy it properly. Therefore, its
EnsureContentIterator(), destructor, traverse and unlink code becomes messy.
However, ScriptableContentIterator was designed for automated tests and we
need to maintain it not so many times. Therefore, improvement of other
users must be worthwhiler than this demerit.
Differential Revision: https://phabricator.services.mozilla.com/D15928
--HG--
extra : moz-landing-system : lando
Now, nobody requires nsIContentIterator interface. So, we can get rid of it.
Unfortunately, there is no macro to keep the inherited class,
ContentSubtreeIterator, in the cycle collection to make it keep managing
ContentSubtreeIterator::mRange without nsISupports interface. Therefore, this
patch moves it into ContentIteratorBase temporarily. Anyway, the following
patch makes those classes not refcountable. At that time, this issue will be
fixed.
Differential Revision: https://phabricator.services.mozilla.com/D15927
--HG--
extra : moz-landing-system : lando
Now, all users of ContentSubtreeIterator can access it directly. This patch
makes them use the concrete class directly.
Differential Revision: https://phabricator.services.mozilla.com/D15920
--HG--
extra : moz-landing-system : lando
If there is no scrollable frame, PresShell::GetScrollableFrameToScroll() returns
nullptr. However, even when we don't expand selection, we need to move caret
in current selection root. Therefore, it should call
nsFrameSelection::CommonPageMove() with the result of
nsFrameSelection::GetFrameToPageSelect() to move caret.
Differential Revision: https://phabricator.services.mozilla.com/D16020
--HG--
rename : layout/base/tests/test_expanding_selection_per_page.html => layout/base/tests/test_moving_and_expanding_selection_per_page.html
extra : moz-landing-system : lando
Port to separate SpatialId from ClipId in Webrender API (WR PR #3251).
Patch was originally written and reviewed on bug 1503447.
Depends on D16005
Differential Revision: https://phabricator.services.mozilla.com/D16006
--HG--
extra : moz-landing-system : lando
The focus event listener in editor is system group, so synthesizeKey and/or synthesizeMouse doesn't work on focus event since editor doesn't initialize selection yet. So use setTimeout to work synthesizeKey and etc well.
Differential Revision: https://phabricator.services.mozilla.com/D15926
--HG--
extra : rebase_source : bbedd32278c94f009c7ab0e9d685979887b2f031
The layout module is a little weird. It's described as being loadable
in the GPU process, but very few of the contracts and CIDs it contains
are also marked as such. In fact, the sole reason the layout module is
marked as being loadable in the GPU process is so that the power manager
service can be registered; everything else is inconsequential. This
setup also means that the initializer for the layout module has to
specifically check whether it's running in the GPU process (or several
other processes...), so we don't try to spin up a bunch of stuff we
don't need, like xpconnect and similar.
This setup is silly: we should have a module solely for the power
manager's use and that module can be loaded in the GPU process. Then
the layout module can go back to being an ordinary module, and we don't
have to play games in its initialization method.
This prepares this binding for the unification with the "popup" binding, and removes the last consumer of the scrollByIndex method of XULScrollElement.
Because some code paths in "arrowscrollbox" are optimized using requestAnimationFrame, the related scrolling tests are now asynchronous.
Differential Revision: https://phabricator.services.mozilla.com/D15276
--HG--
extra : rebase_source : f5d26df106785f2c0d158b8a23a648a71ab06b2d
Per our discussion, this patch splits out the state management bits of
WebRenderLayerManager, allowing for them to be maintained per-document.
Differential Revision: https://phabricator.services.mozilla.com/D13577
--HG--
extra : moz-landing-system : lando
This Make nsSVGIntegrationUtils::AdjustInvalidAreaForSVGEffects return the
original area if there are no filter effects (instead of using some bogus
fallback code).
Differential Revision: https://phabricator.services.mozilla.com/D16516
--HG--
extra : rebase_source : 16de5f99068e5c219f4f366af848ae3cc6c83417
extra : amend_source : 62f0d870192421a58bbf6f7f083c6614c936ac3b
This is the closest to the spec behavior, I think, and less likely to
cause interop issues, but if you prefer me to stop the 'inheritance' chain at
contenteditable elements or what not I can also do that.
Differential Revision: https://phabricator.services.mozilla.com/D15963
--HG--
extra : moz-landing-system : lando
This commit adds a debug pref that will highlight the frames that are marked as
anchor nodes. This is helpful to debug anchor selection.
Differential Revision: https://phabricator.services.mozilla.com/D13276
--HG--
extra : rebase_source : 4b782de348454ad5660366814d4fe290ff2be152
extra : source : d8eef8f3e396d3a6f82607f53fc280316f184e86
This commit implements the second half of the heuristics to detect style changes
that could lead to feedback loops with scroll anchoring. [1]
A new change hint is added for when a style is changed from positioned to not
positioned. When this hint is applied, scroll anchor suppression is triggered in
the scroll anchor container where the frame used to be, and the new scroll
anchor container where the frame is added after reconstruction.
[1] https://drafts.csswg.org/css-scroll-anchoring/#suppression-triggers
Differential Revision: https://phabricator.services.mozilla.com/D13273
--HG--
extra : rebase_source : 085c7d6b62c3f52122d9ae57eded71a1de2527a1
extra : source : e76b842c7b7fbdf434de7f099e399a8a53753493
This commit implements the first half of the heuristics to detect style changes
that could lead to feedback loops with scroll anchoring. [1]
When these style changes are made, a suppression flag is added to the anchor
container to ignore any adjustments that would be made at the next layout flush
and to invalidate the anchor at that time.
[1] https://drafts.csswg.org/css-scroll-anchoring/#suppression-triggers
Differential Revision: https://phabricator.services.mozilla.com/D13271
--HG--
extra : rebase_source : db0bf373e51325b7ef537c4c245ede4b4219d0d7
extra : source : d9445a5f3458b560fbdb7aee5faabb5a7a9327f3
This commit implements anchor offset adjustment. When the position of a frame
that is an anchor is changed during reflow, we notify the anchor container. The
anchor container will then post a reflow callback.
Then when reflow is completed, the anchor container will perform a scroll to
keep the anchor node in the same relative position.
Differential Revision: https://phabricator.services.mozilla.com/D13270
--HG--
extra : rebase_source : 9d40a5d5b73777d0da3799f162eeb85bb8e6d8f0
extra : source : d9052f7b34d9857863b66d64797f8b0b82504bec
This commit adds a mechanism for scroll anchor containers to request an anchor
node selection at a future time. Currently this is before styling so that anchor
adjustment suppression will have current anchor nodes.
Differential Revision: https://phabricator.services.mozilla.com/D13269
--HG--
extra : rebase_source : 7af2dcc7953e446eb993625fa7ff32aa5a141eab
extra : source : e7124fecb7215769a5404c5f2268bbe715162393
This commit implements candidate selection for a scroll frame using a frame tree
traversal. It roughly tries to follow the algorithm given in the scroll
anchoring draft specification, adapted to operate on the frame tree [1].
Some details, such as not selecting an anchor if the user hasn't scrolled are
not currently in the specification but will be to match Blink's implementation.
Once a scroll anchor has been selected, we maintain a bit on it and its ancestor
frame's states. This is used in a later commit to detect changes to position
during a reflow so the scroll frame can perform an adjustment.
A scroll anchor will be invalidated when the user scrolls the frame or the
scroll anchor is destroyed. Later commits will add logic to drive selection and
invalidation appropriately.
[1] https://drafts.csswg.org/css-scroll-anchoring/#anchor-node-selection
Differential Revision: https://phabricator.services.mozilla.com/D13268
--HG--
extra : rebase_source : e05ba48662aafef5957322def33ddc5d93f3ca5a
extra : source : bdb766faa8679386bf4e9740781262ea4bb36544
This commit adds a barebones class called 'ScrollAnchorContainer' that will
contain most of the logic for scroll anchoring. It is owned as a member of
ScrollFrameHelper, and has the same lifetime.
Differential Revision: https://phabricator.services.mozilla.com/D13267
--HG--
extra : rebase_source : 41f6f7691af60401f18f98a89f1878cfad2e74d3
extra : source : 3033401ef320414ef5f489c53526d015c38a89d7
This commit is used in a later commit to exclude frames that are sticky positioned
from being scroll anchors.
Differential Revision: https://phabricator.services.mozilla.com/D13266
--HG--
extra : rebase_source : efa0b81269dbf55d14d5702e4e4d4970cce2e5cb
extra : source : 6b96050386f6e9bae6b61747145e204d12cd7cf3
This restores the previous behavior of using calc().
Note that background-position / object-position, which test this, weren't
hitting the assertion because they use another codepath.
I didn't add more extensive tests for this because it's well tested for those
two properties, and because this is legacy anyway, see the comment in the test.
I did add the assertion to the codepath those two properties hit.
Differential Revision: https://phabricator.services.mozilla.com/D16176
It does not represent `<length> | <percentage>`, but `<length-percentage>`, so
`LengthOrPercentage` is not the right name.
This patch is totally autogenerated using:
rg 'LengthOrPercentage' servo | cut -d : -f 1 | sort | uniq > files
for file in $(cat files); do sed -i "s#LengthOrPercentage#LengthPercentage#g" $file; done
Differential Revision: https://phabricator.services.mozilla.com/D15812
--HG--
extra : moz-landing-system : lando
The concrete classes of nsIContentIterator are enough complicated, but they
are not tested simply. Therefore, it's dangerous to touch them even if we
meed bugs of them. Additionally, it's used in some hot paths, therefore,
I'd like to keep them simple as far as possible.
Therefore, this patch creates a mediator class between script and each
nsIContentIterator instance. So, this change shouldn't affect any of
actual behavior nor performance.
Differential Revision: https://phabricator.services.mozilla.com/D15285
--HG--
extra : moz-landing-system : lando
I think this should do. This still prints out stderr when it fails pointing to
the solution, and doesn't fail the build.
Differential Revision: https://phabricator.services.mozilla.com/D15784
--HG--
extra : moz-landing-system : lando
The XBL binding implementation relied on nsDateTimeControlFrame to call into
its nsIDateTimeInputArea implementation. This is correct because the XBL binding
is only constructed when the element has a frame. If the value is set while the
element is hidden, the XBL binding will pick up the correct value during construction.
That is not the case for UA Widget. As it is constructed when the DOM is attached,
relying on nsDateTimeControlFrame to send an event when attributes change means
the event won't be sent to the already constructed UA Widget.
This patch fixes that by moving the event dispatching calls originating from
HTMLInputElement out of nsDateTimeControlFrame, so they will behave correctly in
the absence of the frame.
I've also moved the gut of nsDateTimeControlFrame::HasBadInput() to
DateTimeInputTypeBase::HasBadInput(). Content script should be allowed to validate
the input without the frame.
Sadly this means the XBL implementation and the UA Widget implementation
have further diverged. The complexity should go away when we could finally
remove the XBL implementation.
nsDateTimeControlFrame still dispatches a few events to UA Widget, in
AttributeChanged() and SyncDisabledState(), as they are originated from the layout.
The name of the events in AttributeChanged() are incorrect though -- I am correcting
that in this patch too.
Differential Revision: https://phabricator.services.mozilla.com/D15601
--HG--
extra : moz-landing-system : lando
This converts the tabmodalprompt binding to a class, to be constructed along side with the element
by TabModalPromptBox.
TabModalPromptBox will keep the instances in a map and pass it to the callers, instead of the element.
The tests and callers can access the class instance by passing the element reference to the map.
Differential Revision: https://phabricator.services.mozilla.com/D15505
--HG--
rename : toolkit/components/prompts/content/tabprompts.xml => toolkit/components/prompts/content/tabprompts.jsm
extra : moz-landing-system : lando
After Bug 1507244 Part 2 landed, only block or inline frames can have
NS_FRAME_HAS_MULTI_COLUMN_ANCESTOR bit set. We need to fix
IsColumnSpanInMulticolSubtree() for other types of frames.
In multi-column formatting context, every frame having a
"column-span:all" style will be wrapped by a -moz-column-span-wrapper
frame. We can use this to check whether a non-inline and non-block frame
is in a multi-column subtree or not.
Differential Revision: https://phabricator.services.mozilla.com/D15709
--HG--
extra : moz-landing-system : lando
It was enabled by default in bug 1041833 (for desktops) and
bug 1087562 (for Fennect).
Depends on D15706
Differential Revision: https://phabricator.services.mozilla.com/D15707
--HG--
extra : moz-landing-system : lando
By disallowing flushing layout in AccessibleCaret's callbacks, we don't
need to worry about dead PresShell affect other callbacks in the system.
Differential Revision: https://phabricator.services.mozilla.com/D15537
--HG--
extra : moz-landing-system : lando
Without this change, for example,
UpdateCarets(UpdateCaretsHint::DispatchNoEvent) won't update carets. We don't
have a wrong use case yet, but it's good to fix that beforehand.
Differential Revision: https://phabricator.services.mozilla.com/D15535
--HG--
extra : moz-landing-system : lando
GetParent() already returns nsContainerFrame*, and it's easier to use
with API like FinishBuildingColumns() demanding a nsContainerFrame*.
Differential Revision: https://phabricator.services.mozilla.com/D15549
--HG--
extra : moz-landing-system : lando
There is no reason to use nsAtoms*, it's error prone, i.e. the function
can take arbitrary nsAtoms*.
Depends on D15339
Differential Revision: https://phabricator.services.mozilla.com/D15340
--HG--
extra : moz-landing-system : lando
This is a big step in order to merge both.
Also allows to remove some very silly casts, though it causes us to add some
ToSupports around to deal with ambiguity of casts from nsIDocument to
nsISupports, and add a dummy nsISupports implementation that will go away later
in the series.
Differential Revision: https://phabricator.services.mozilla.com/D15352
Just use nsTArray. They're used to keep an array of strong references to
documents, and never use nsISupports-specific methods.
Plus they're are allocated on the stack so it should be safe to access them via
ranged for, so do that.
This is needed because nsCOMArray<T> depends on the cast from T to nsISupports
not to be ambiguous. I could fix that if needed, but it seems easier to just not
use it in these two cases.
Differential Revision: https://phabricator.services.mozilla.com/D15351
This is to prevent Part 1 from breaking
testing/web-platform/tests/css/css-multicol/multicol-span-all-restyle-002.html
After introducing Part 1, we now use CreateContinuingFrame() to create
non-column-span wrapper frames, which use nsFrame::Init() rather than
InitAndRestoreFrame() to initialize them. Because the bits in
aState.mAdditionalStateBits are added to frames only when
nsCSSFrameConstructor::InitAndRestoreFrame() is called. We need a new
way to add the NS_FRAME_PART_OF_IBSPLIT to non-column-span wrapper
frames.
Note that we used to add NS_FRAME_PART_OF_IBSPLIT to both column-span
wrapper and non-column-span wrapper. After this patch, column-span
wrapper won't have NS_FRAME_PART_OF_IBSPLIT. That's fine because
column-span wrappers are not linked with other frames and they
shouldn't get this bit set.
Depends on D15134
Differential Revision: https://phabricator.services.mozilla.com/D15452
--HG--
extra : moz-landing-system : lando
In CreateColumnSpanSiblings(), aInitialBlock can be a DetailsFrame.
Therefore, when creating a non-column-span wrapper, we cannot assume
it's always a block frame. We need to use CreateContinuingFrame to
ensure the correct type of continuation is created.
Differential Revision: https://phabricator.services.mozilla.com/D15134
--HG--
extra : moz-landing-system : lando
This hopefully will address the test-verify failures that were reported in bug 1516006.
--HG--
extra : rebase_source : d01139f16469c631eb047d21e998dfaf0d58c3a5
extra : amend_source : 8543fd2e10bf485cabaf45dfac156e6b9094ea41