* The number is no longer selected on number input focus
MozReview-Commit-ID: AmR5c6YKTCP
--HG--
extra : rebase_source : fdaab23fca57f361c9185191d9c30e047375cbe8
Changing the transaction id allocator is now handled better in
ClientLayerManager than before in that it resets the transaction id on
the new allocator to match the old allocator and avoid discontinuities
in the transaction ids. We should apply this behaviour to
WebRenderLayerManager as well, because WebRenderLayerManager was
assuming that any time the allocator changed it would automatically
start the transaction id at 1, which is not the case. In particular,
when navigating to something in the bfcache, we can reuse a pre-existing
refresh driver which might have a transaction id already greater than 1.
MozReview-Commit-ID: 8IUn1Dhnh7c
--HG--
extra : rebase_source : 0e98c96d9636c3a3ee0489ff6b6161bce7677dd7
If there is an active provider which has yet to produce a frame, any
calls to SurfaceCache::Lookup will return MatchType::PENDING. If
RasterImage::Lookup gets the above result while given FLAG_SYNC_DECODE,
it will attempt to start a new decoder. It is entirely possible that
when we try to insert the new provider into the SurfaceCache, it cannot
because the original provider finally did produce something. In that
case we should abandon attempting to redecode and retry our lookup.
EditorBase::JoinNodeDeep() returns a DOM point which was start of right node.
Currently, this is set before actually joining the nodes. Therefore, we see
warnings since right node which becomes joined node may have less children
than left node.
This patch also makes the NS_WARNING_ASSERTION to NS_ASSERTION since no tests
hit this. So, we can use it to detect regressions.
MozReview-Commit-ID: 3RmRP588AkF
--HG--
extra : rebase_source : 2cab458ffac566c81eb8d3f47e755ffacb1553d2
It seems reasonable to assume that when a page has been granted permission
to capture camera/microphone, the user intends it to play audible media.
MozReview-Commit-ID: 1RdsPK1vRPt
--HG--
extra : rebase_source : 688b68c29d73f117a2cc376233d664bc9cdb5d52
Added derive(ToCss) annotation : WIP
<!-- 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: -->
<!--
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable). -->
<!-- Either: -->
<!--
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
-->
<!-- 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: 0653f3097c07cac0a44e8a1bb1d431885edd7de0
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 3b3418f5efde33cfd000b0341b523336c14485c9
It doesn't fill the ancestors of the first frame if aCommonAncestor is null,
which means that we get garbage afterwards.
MozReview-Commit-ID: G85dv7KM1Xd
In particular, even when there are no frames, we may have used the rule
cascades / stylist data (for different stuff, like font-feature-values, thus the
regressing bug).
Using the old rule cascades / stylist data without knowing it has changed is
wrong, thus the bug.
Now that media query change stuff is async and has a well-defined processing
point, we should be able to just call it without too much worry.
Also note that at the point the extra hints are passed, if there's no root frame
/ elements are not styled / etc, we'll optimize away the change hint.
The test-case intermittently fails without this patch, but I didn't manage to
make a better one, unfortunately :(
MozReview-Commit-ID: LY2HRIlAKHX
The reason why bug 1355721 regressed this is because in non-e10s we definitely
flush before parsing the standards quirks-mode. And bug 1355721 introduced an
unconditional UpdateStylistIfNeeded, unless the counter style / font
equivalents.
That means that the stylist wouldn't remain on its initial state after the first
flush, which itself means that when the compat mode changed, the UA and user
rules were already on the stylist with the quirks mode keys. That makes
class-names be keyed in ascii lowercase.
After that no user style changed, so no rebuild happens for the cascade data in
the user origin, so we keep looking at the wrong keys indefinitely.
MozReview-Commit-ID: 25dD2bca3tN
The reason why bug 1355721 regressed this is because in non-e10s we definitely
flush before parsing the standards quirks-mode. And bug 1355721 introduced an
unconditional UpdateStylistIfNeeded, unless the counter style / font
equivalents.
That means that the stylist wouldn't remain on its initial state after the first
flush, which itself means that when the compat mode changed, the UA and user
rules were already on the stylist with the quirks mode keys. That makes
class-names be keyed in ascii lowercase.
After that no user style changed, so no rebuild happens for the cascade data in
the user origin, so we keep looking at the wrong keys indefinitely.
We should try to avoid the flush there and ensure that by the time we create a
pres shell the quirks mode is already up-to-date...
Bug: 1394233
Reviewed-by: xidorn
MozReview-Commit-ID: 25dD2bca3tN
Source-Repo: https://github.com/servo/servo
Source-Revision: 2ec0b50ebc65f04a49420e15267f564d36d5ada1
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 763cfe74f08d44b02b166be1c2077b3f4d97e8f5