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
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
This is a just a back out of changeset 6882857e1bb5.
MozReview-Commit-ID: 9Z6iEHl3eAy
--HG--
extra : rebase_source : 3d091c72a6e589e702d90ffe6800e131b009604b
Originally image decoding tasks were processed in a FILO ordering, due
to that being the most efficient way to use an nsTArray as a queue. This
patch changes the decoding pool to use an std::queue to promise FIFO
ordering (relative to the priority of the tasks). This will allow the
first images to be requested to be the first images displayed.
The image decoding thread pool can grow to be quite large, up to 32
threads, depending on the number of processors on the system. If the
user is not actively browsing, these threads are occupying resources
which could be reused elsewhere. After the timeout period, it will
release up to half of the threads in the pool.
Currently imagelib's DecodePool spawns the maximum number of threads
during startup, based on the number of processors. This patch changes it
to spawn a single thread on startup (which cannot fail), and more up to
the maximum as jobs are added to the queue. A thread will only be
spawned if there is a backlog present when a new job is added. This
typically results in fewer threads allocated in the parent process, as
well as deferred spawning in the content processes.
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
