In the case where we throttle transform animations in visibility:hidden
element, we just need to unthrottle only if the element is scrolled out since
unlike the scrolled out element, visibility:hidden element keeps invisible
even after the element moved into view.
MozReview-Commit-ID: 7X2SsOLz4Y5
--HG--
extra : rebase_source : ca7210f7ed637f858127c4008fe98fbeec874a10
This patch does basically throttle animations on visibility:hidden element
and unthrottle it once the animating element became visible or a child of the
animating element became visible. But still there are some cases that we don't
throttle such animations perfectly. For example;
div.style.visibility = 'hidden'; // the 'div' has no children at this moment
div.animate(..);
// The animation is throttled
div.appendChild(visibleChild);
// The animation isn't throttled
visibleChild.style.visibility = 'hidden';
// Now the animation should be throttled again, but actually it's not.
To throttle this case properly, when the |visibleChild|'s visibility changed
to hidden, we would need to do either
1) Check all siblings of the |visibleChild| have no visible children
or
2) The parent element stores visible children count somewhere and decrease it
and check whether the count is zero
To achieve 1) we need to walk up ancestors and their siblings, actually it's
inefficient.
2) is somewhat similar to what we already do for animating images but it's hard
to reuse it for CSS animations since it does not take into account that
descendants' visibilities.
Another example that this patch does not optimize is the the case where
animating element has children whose visibility is inherited and the element
itself initially visible something like this;
let child = document.createElement('div'); // child visibility is 'inherit'
div.appendChild(child);
div.animate(..); // the 'div' is visible
// The animation isn't throttled since the animating element is visible
div.style.visiblily = 'hidden';
// Now the animation should be throttled, but it's not since this patch does
// not descend down all descendants to check they are invisible or not when the
// animating element visibility changed to hidden.
This patch adds a test case for this case introduced with todo_is().
Another test case added in this patch fails if we don't use
nsPlaceholderFrame::GetRealFrameFor() in HasNoVisibleDescendants().
MozReview-Commit-ID: BJwzQvP9Yc4
--HG--
extra : rebase_source : e56505706bb2799b59bbfb3bbcce4a9ce86892f4
This new change hint doesn't influence layout so that it can be regarded
as nsChangeHint_Hints_CanIgnoreIfNotVisible. Note that if visibility changed
from collapse or to collapse, we set NS_STYLE_HINT_REFLOW separetely.
MozReview-Commit-ID: AirDWeBYVKG
--HG--
extra : rebase_source : a462845ac2d8280986bb8db5e6482bf401f65322
Replace the one use of it with element.focus().
MozReview-Commit-ID: 5qK6yfyuRoY
--HG--
extra : rebase_source : f6f9a738c6ebf2201dbd6a2ac5fe476797e0adb5
In our current implementation for media query stuff, it's possible to change
media features inside the callback for media query list events and the events
are dispatched at an early stage in flush pending styles. Whereas at a later
stage in flush pending styles, we don't allow pending media feature changes.
According to the spec [1], the media query list events have to be dispatched
in a different place from flush pending styles. We have to move the event
handling someday, but as for test_contentViewer_overrideDPPX.html, we don't
need to change media features inside the callbacks (precisely it has done
inside a Promise for the callbacks), so we add setTimeout call to make sure
the media feature changes are processed after the flush pending styles.
[1] https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-8
MozReview-Commit-ID: 5VoQJ1uGUwD
--HG--
extra : rebase_source : 47443f7dc00aa62a35f570796eeec547526d8142
It tries to serialize unquoted family names as a series of identifiers. For family names which contain special white spaces like leading white space, trailing white space, and consective white spaces, unquoted names are marked quoted in parsing to avoid complicating serialization code.
This fixes [bug 1434802](https://bugzilla.mozilla.org/show_bug.cgi?id=1434802).
Source-Repo: https://github.com/servo/servo
Source-Revision: 3d6ce6c36aab3229929db3d49a8fec94dcf16f66
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 715a879e920a8d0776412f48607b26a2d38e9d8c
These conditions are rare and do indicate a problem which breaks accessibility.
However, we aren't getting any closer to diagnosing these as a result of these crashes, so they cause user pain without any gain to us.
MozReview-Commit-ID: D9U4et3Bg7d
--HG--
extra : rebase_source : a81263a0ef97a8ed87129d15ef30ded3005e740c
Due to bug 1193394 triggering a Promise in the event loop causes the Promise to be
resolved after the event loop microtask.
In this particular case the result is that the document localization is triggered
right before initial layout, but is executed much later, only after DOMContentLoaded.
This in turn causes an additional reflow and frame creation.
In order to workaround this, we're adding a callback method that is executed synchronously
after the event resolves which puts back the initial document localization to happen
right before layout.
MozReview-Commit-ID: HXuMJPwS24N
--HG--
extra : rebase_source : 7d5065658e9873dde2d61964dcb22e209cc6d4f6
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] Added unit tests and wpt for these changes
- [x] These changes fix#19958
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 62e1fc7899c2b0210dd24044d388b43ae80c276c
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 148314440b92a4f50ef93e97133ada5afe168ec1
In partiuclar: nsCSSRenderingBorders.cpp is already using IsBoxDecorationSlice
and BoxDecorationRectForBorder. This would be compile error, except that we
happen to unify the two .cpp files together. This patch promotes these two
functions (along with a closely-related function, for consistency).
MozReview-Commit-ID: 4sWj5Rb9QSw
--HG--
extra : rebase_source : 542f0200a82121f13626c9c2d129fcb5c441ff45
As well as flipping the pref on, this also moves the pref to the common all.js
prefs file because the pref is used by DevTools server code.
MozReview-Commit-ID: GfkLfXg1EiR
--HG--
extra : rebase_source : 952dcc4bce3f9f2ae598a98be3b63a70ba4068b2
See the comment on "Address test failures caused by bumping timer precision to 2 ms"
for more details.
MozReview-Commit-ID: LrsucEPdZIo
--HG--
extra : rebase_source : 8147c034f7dc93f678eebc80b0afabf55729d804
Previously we weren't explicitly installing sphinx. Instead, the 'sphinx-js'
package had a dependency on 'sphinx<2.0'. This caused errors when sphinx
released their backwards incompatible version 1.7.
This patch pins sphinx==1.6.7 and adds all other dependencies to the same
requirements.txt (with hashes).
Upgrading to sphinx==1.7 will happen in a follow-up.
MozReview-Commit-ID: 28fKI7T4vfa
--HG--
extra : rebase_source : a9f276586ed08f49c1a26088aae88c363a31c167
In the previous code, a race condition could cause us to call SendSetPriority() after calling SendDeleteSelf.
For example:
T1: SendDeleteSelf()
T2: if (!mIPCClosed) SendSetPriority()
T1: mIPCClosed = true
MozReview-Commit-ID: 3XOwCaphb2o
--HG--
extra : source : 4ebdab0e332892378558817e30d0138c95199ce5
extra : intermediate-source : fc4ad53516e01095be35542fd979c9e16d6e6b16
If the duration was 0ms, it would not be cleaned; and thus lead to a mismatch and
ultimately test failure.
MozReview-Commit-ID: 1s9nMzlGT0e
--HG--
extra : rebase_source : 6c5dfe6dcc4fcf767d5b47878f09f3d1089d8dd2
This test is an exact duplicate of browser_webconsole_variables_view_while_debugging_and_inspecting.js
except it doesn't start the inspector before performing the test.
I don't think it's worth keeping and maintaining both tests.
MozReview-Commit-ID: 7EcdVmJjAfu
--HG--
extra : rebase_source : 3204d7c3f6c930330d3cb4d65f7b1dacac594dba
This warning is triggered by the use of alignas() in js/public/RootingAPI.h.
Now that GeckoProfiler.h includes RootingAPI.h, this warning is encountered
when building security/certverifier because GeckoProfiler.h is already being
included transitively, through this inclusion path:
CertVerifier.cpp -> CertVerifier.h -> Telemetry.h -> StartupTimeline.h -> GeckoProfiler.h
However, this explanation is not entirely satisfactory, because there seems to
be an existing inclusion path for RootingAPI.h already:
CertVerifier.cpp -> CertVerifier.h -> BasePrincipal.h -> OriginAttributes.h
-> ChromeUtils.h -> ChromeUtilsBinding.h -> RootingAPI.h
So I'm not quite sure why this problem is only starting to happen now.
MozReview-Commit-ID: AFuXpTjdPsi
--HG--
extra : rebase_source : 60f74c8655d15fbc6acbf0ce8a2f208e198e231e
This commit does several subtle things.
1: It changes ok() to opener.ok()
ok is not defined, we have to use opener.ok. This was not caught before because
this call is used to provide additional debugging information when a test fails.
Test didn't fail, didn't hit that line.
2: It disables the call to opener.ok() we just fixed.
As the comment there describes, we expect that function to fail, so we don't want
to assert(false).
3: It inverts failures to successes if only the reduceTimerPrecision pref is set
MozReview-Commit-ID: lpKKhJoDs6
--HG--
extra : rebase_source : 0d29f2b6061526abe989c4b58397bb78631cec7b
There are a few different reasons why tests needed updating (not an exhaustive list):
- Tests assume that successive operations take place at different times.
- Tests assume that an operation took a minimum amount of time.
- Tests hardcodes a specific delay.
In most cases we hardcode the preference off. In some cases this is the best approach,
in others, we would like to improve. The bug for tracking those improvements is Bug 1429648
An improvement that is present in some tests is to hardcode a specific precision reduction
that is acceptable based on the confides of the test. (Obviously this needs to be a fix for
the test framework and not a requirement on the feature being tested.)
In a few places, the test itself can be fixed, for example to no longer require the end
time of an operation to be strictly greater than the start time, and allows it to be equal
to it.
MozReview-Commit-ID: J59c7xQtZZJ
--HG--
extra : rebase_source : df8a03e76eaf9cdc9524dbb3eb9035af237e534b
This patch creates the capability to have callsites specify if timestamps
should be clamped only in Resist Fingerprinting Mode, or in the more expansive
Timer PRecision Reduction Mode.
Then it changes the CSS Animation callsite to only apply in RFP Mode.
This avoids regressing RFP.
MozReview-Commit-ID: B1pSri0kRk6
--HG--
extra : rebase_source : f3d8c1f9561fbb19d1ca8594ba2b69cffd25445b
We were not correctly setting the menulist value for default popup permissions,
which went largely unnoticed so far because the user had no way of actually setting
these permissions explicitly. It might happen with policy engine in the future
and so we should fix this.
MozReview-Commit-ID: 1VQc1NRGGX
--HG--
extra : rebase_source : 91dd30d11913316e1fc50c09b3ca37ae6430c938
Just some more use-cases that can be converted right away.
I'm trying to make XBL not use a whole Stylist, slowly...
Source-Repo: https://github.com/servo/servo
Source-Revision: 63691f01d79874aae4bb84badf86667c863cec9b
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : da4fa29f65cb29a337b99877f44fe18db26ee4b9