Per definition of this bug/patch, key shortcuts can't be registered anymore.
It mostly means that add-on definition a key shortcut won't keep their key shortcut working.
This shouldn't be an issue on 57 as I don't think WebExtension addon can set a key shortcut via this DevTools API.
MozReview-Commit-ID: G5c8JzaUWoR
--HG--
extra : rebase_source : d9cda8d4af63af795e8f66d3bee7e442bd78d939
Now that devtools-browser is lazily evaluated, we have to create the widget early in devtools-startup.
MozReview-Commit-ID: JanbAPalYE1
--HG--
extra : rebase_source : 2625da986184d5a1f8b3ce293da4e16fdb5ed339
The new video decoder in CDM version 1.4.8.970 seems to calculate its frame size
as about 1.5X of the optimal size. So increase our estimate of CDM video frame
buffer sizes by more than that so that our pre-allocated buffers should be big
enough to accomodate the allocations that the CDM requests.
This means we should be more likely to avoid the slow fallback path where we
have to transfer frames from the CDM to the content process using the non-shmem
path.
MozReview-Commit-ID: 6PT8XVCAL3E
--HG--
extra : rebase_source : a27793b033c4f50f6e15d874558dc50e1410c8be
The strategy we were using to expand the pool of shmems we use to shuffle video
frames between the CDM and content processses is to increase the size of the
pool if the content process receives a video frame in a non-shmem. However the
CDM process will send a frame in a non-shmem if none of the shmems in the pool
are big enough to fit the frame the CDM produces. This happens if we
underestimate the size required for video frames. This causes the
ChromiumCDMParent to increase the number of shmems in the pool every time we
rate switch, until we eventually hit the limit of 50, whereupon playback fails.
So we need to disambiguate between these two cases; the first being we have a
pool of shmems, but they're the wrong size, the second being our shmems are the
right size, but we've run out and we need to expand the shmem pool. The only
place where we know this is in the CDM process. So this commit adds a new
message to PChromiumCDM through which the ChromiumCDMChild can report to the
parent that it needs more shmems in the pool.
The new Widevine CDM has a new video decoder which allocates video frames less
optimally than the previous, which causes us to hit this more often in Nightly.
Our telemetry also indicates we hit this rarely in Beta with the old CDM.
MozReview-Commit-ID: LoSvVhxHQxn
--HG--
extra : rebase_source : 6c7201a74dbf202d0ef8c2269292a80a7ad95dff
extra : source : 57cf5455fd14ef0b68b61f914146ff942b5ca4a0
This is largely just a translation of Gecko's PropertyPriorityIterator[1] into rust with the exception that IDL sort order is only defined for shorthands since that's all we currently require.
[1] http://searchfox.org/mozilla-central/rev/3a3af33f513071ea829debdfbc628caebcdf6996/dom/animation/KeyframeUtils.cpp#151
---
<!-- 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 --stylo` does not report any errors
- [x] These changes fix (Gecko bug 1371493)[https://bugzilla.mozilla.org/show_bug.cgi?id=1371493].
- [x] There are tests for these changes OR
<!-- 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: a47fde038e893d4b76d64b6917085d8e5bc9d8d1
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 6efde1ea0b3969b0d48c0e0f7285dec284a9a8b1
The KeyframeEffectReadOnly::GetProperties compares AnimationValue's mGecko
member which means it sometimes produces the wrong results when using the Servo
backend. Now that AnimationValue has a suitable operator!= method we can simply
compare the AnimationValues directly.
MozReview-Commit-ID: DQQbmcdeynw
--HG--
extra : rebase_source : 509230cf460308b0a534fe9831e9e0d7fa3b8bee
This reftest fails without the first patch on stylo.
MozReview-Commit-ID: E5pBzBw9x8B
--HG--
extra : rebase_source : 4fe2a99bfed76d1b5fb320ef6a4f2b39ee5f5f2c
This test fails without the first patch in this series.
MozReview-Commit-ID: A22aFPnklqj
--HG--
extra : rebase_source : c3a4e1f1dea0444895a3b60c45814c219ff65ac6
In case of pseudo element, AnimationsWithDestroyedFrame holds the parent
element instead of generated pseudo content, so the primary frame of the
holding content is not the primary frame for pseudo elements. We need to
check correct primary frame respectively.
MozReview-Commit-ID: DleEoV13G1f
--HG--
extra : rebase_source : 9b9ed696eeb088b919e2dc81bd618d333a3284ba
This only makes use of the "Solid" text decoration type, which
matches the existing support. WR now supports dotted, dashed
and wavy text decorations, but supporting those will need some
extra work in Servo to pass through the correct values.
Source-Repo: https://github.com/servo/servo
Source-Revision: 46ffcbaf7bc97df7c8ba3b82add0e03a01805ab4
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 97baccf41b67fd0c743bd96d4917e8b7ef6b0a7f
In bug1371202, it has already implemented what I want to do, so remove the
change in bug1367980.
MozReview-Commit-ID: LoH51bBDTqr
--HG--
extra : rebase_source : 9fd77acae81f94e45f0f840775c81509e85c4ad0
Since now MFR doesn't need an AbstractMediaDecoder at all, we can
now remove BufferDecoder which exists as an empty shell to implement AbstractMediaDecoder.
MozReview-Commit-ID: HpEcK0mfpeh
--HG--
extra : rebase_source : e4d58d3b706aaf6ee005b9f82a668dd38efc2200
extra : intermediate-source : caa1e64b1a0216773d31854341075858a8dc2d0f
extra : source : c644912a8eeed0a18d61e11a3bcc92a39a6de483
So we can remove the use of AbstractMediaDecoder::NotifyDecodedFrames().
MozReview-Commit-ID: Ch7Saha6zdi
--HG--
extra : rebase_source : 8562faa56d1f31797643ed0f7ae550765d8c86d7
extra : intermediate-source : 05b50517cc40f2adf06facfccea628488dd319da
extra : source : d5af89f5a09e03c8fbb0d6111f88e3221f3a1d57
Currently, nsMenuBarListener::KeyPress() handles F10 key before remote content handles it. However, if a remote process has focus, the keyboard event should be handled in the content first. Then, only when it's not consumed in the remote process, menubar should handle the F10 key press.
MozReview-Commit-ID: GDf4POAPsTy
--HG--
extra : rebase_source : a450755d89bc410d17fef55fad98533169e2eff5
<!-- Please describe your changes on the following line: -->
The step annotations in the code were outdated, and did not match the spec: https://html.spec.whatwg.org/multipage/scripting.html#prepare-a-script
Source-Repo: https://github.com/servo/servo
Source-Revision: 548d65dc7a08805bb941d83304c30a12c834ca90
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : ef2eca3ae500760f769ee50c3daa00abb71d9c43
Update the MediaRecorder principal test to behave more like
test_mixed_principals.html. This involves preloading metadata and using a
longer video to test with. This particular combination currently results in
multiple requests being made for the resource, however this is not a robust
solution in that the behaviour of the MediaCache and associated objects may
change and break this. This fixes the issue for now as best I can tell, but
a follow up gtest or may be a more sensible long term solution.
MozReview-Commit-ID: F9gnnzGt3Cu
--HG--
extra : rebase_source : 73f56e256c21f5a775e0fa2a32606d7f7553bd4e
Carsten "Tomcat" Book
Sean Lee
Marco Bonardo
Emilio Cobos Álvarez
Alexandre Poirot
Sylvestre Ledru
James Graham
Chris Pearce
Louis Chang
Brian Birtles
Hiroyuki Ikezoe
Glenn Watson
Alastor Wu
JW Wang
Masayuki Nakano
Nikhil Shagrithaya
Tomislav Jovanovic
Bryce Van Dyk
gasolin
jwu
Sebastian Hengst