Unlike Gecko, Stylo currently invokes a needless RequestRestyle(Standard)
for this test case (bug 1388560). For this reason, the check right after
re-attaching the orphaned element passes accidentally.
MozReview-Commit-ID: JUG1dgMUQEX
--HG--
extra : rebase_source : a86d72a41c160edc30f83d82179ebe1226b842de
Actually we have a chance to run styling process when we attach an orphaned
element to a document in this test setup. Precisely, we can process a restyle
between rAF callbacks and Promise.then() callback for waitForAnimationFrames().
So if we call RequestRestyle(Layer) when we attach the element to the document
(bug 1388557), the animation starts restyling in the first frame. *BUT* this
behavior will also change once our micro tasks handling becomes the HTML spec
compliance (bug 1193394). When the micro tasks handling changes, we should also
fix a bunch of test cases and test utilities in bug 1388557.
MozReview-Commit-ID: GyH1ofGhXOP
--HG--
extra : rebase_source : 3536c315960150960fd43286b205c03c584d53ca
DOMWindowUtils.isStyledByServo checks not only the preference value but also
STYLO_FORCE_ENABLED value. This is important especially when we run test on
our CI. On our CI, the preference value is false but just STYLO_FORCE_ENABLED
is set.
MozReview-Commit-ID: FKEd5LFwcxf
--HG--
extra : rebase_source : 1ffd8a68a8339babed14f441bf2d69c9ffd9e3ee
We want to avoid to have several cached content processes, one for each
preloaded browser (one per window) and one for the preallocated process.
For that we force the preloaded browser to choose an existing process and
during the first navigation in that tab, that leaves about:newtab, we re-run
the process selecting algorithm
The original duration I wrote is calculated from the m3u8 file this is too accurate without error tolerant.
The state machine will update playback position periodically(UpdatePlaybackPositionPeriodically)
according to the clockTime or max end time from A/Vsink.
So the duration will be variant that I should consider to set the value to a more relaxed value.
MozReview-Commit-ID: GGwkhvzz8sI
--HG--
extra : rebase_source : c0465f7aef7a41e999e8c4c3429957fa56336239
Editor treated in nsXBLWindowKeyHandler is always HTMLEditor. So, it should treat the editor as is.
MozReview-Commit-ID: 7uE2p8t5cNW
--HG--
extra : rebase_source : 66b2f42d9d0281f4a244f9cd1ceb077e32ac3515
Editor treated in nsFrameLoader is always HTMLEditor. So, it should treat the editor as is.
MozReview-Commit-ID: 7bZMbLGKsED
--HG--
extra : rebase_source : 47c22423062cd724551ad3b4fde168e03891b4c7
Editor treated by nsFocusManager is always HTMLEditor. So, it should treat the editor as is.
MozReview-Commit-ID: Di1k2dlLodV
--HG--
extra : rebase_source : 49abc56f0a271cdf559adde468d8460ab1ba7aac
In order to expose the JS stack on aync exceptions from the MediaRecorder,
these exceptions must be created at the time of the operation which led to the
exception. E.g. during the start() operation. This changeset creates the
exceptions ahead of time in order to expose the JS stack traces.
MozReview-Commit-ID: HgDJrpjgidD
--HG--
extra : rebase_source : e7ad0b2a30ac2e7161d3805a22b3873a7382b43b
MediaRecorderErrorEvent is now fired in response to async errors in the
MediaRecorder. This event wraps a DOMException and tests need to be updated to
reflect this new behaviour.
MozReview-Commit-ID: JIjIZlJJ8PE
--HG--
extra : rebase_source : f9667b8a1b2a82959624831f3ef5109c19fccbd6
The MediaRecorder is current not behaving as per the spec in regards to async
errors. The spec states that in such a scenario a MediaRecorderErrorEvent which
wraps a DOMException should be fired. This changeset updates the recorder to do
so.
MozReview-Commit-ID: xt4ipCmbiu
--HG--
extra : rebase_source : 50124e6c878438a84c8a440bf79e50b3b7da3998
This adds the webidl definition of the MediaRecorderErrorEvent given in the
spec. It also updates the build system to give us generated C++ code for this
event.
MozReview-Commit-ID: Bi1f0tD9iUj
--HG--
extra : rebase_source : 0cb10aab1a8a8fd7720c5d069cf4ac65817a9855
If a range endpoint is in the middle of a text node, and you call
deleteContents() or extractContents(), the spec says to delete the data
from the node. In the case of extractContents(), the new text node
that's inserted into the DocumentFragment is a clone with its data set
to the bit that was deleted.
<https://dom.spec.whatwg.org/#dom-range-deletecontents>
<https://dom.spec.whatwg.org/#dom-range-extractcontents>
We don't do this. Instead, we split the text node. Then the bit to
delete is deleted naturally at a later stage together with all the other
nodes.
The result is the same, but on the way there we do a bunch more node
mutations. This causes extra mutation records, which cause us to fail a
WPT test. Chrome passes. Changing to match the spec actually reduces
our lines of code anyway.
MozReview-Commit-ID: FTTV5yNSj71
--HG--
extra : rebase_source : 8d5f36c68c71db0700f0b86d1a73462759f922e8
When range is selected table element, Selection.addRange uses nsFrameSelection. If frame isn't constructed yet, addRange throws NS_ERROR_FAILURE even if table element isn't editable element.
When getting nsITableCellLayout, we should flush frame to construct cell frame.
MozReview-Commit-ID: 9qWwW46RYNL
--HG--
extra : rebase_source : 708e78af457a28bc273b83015f78950a5bee232e
Despite the comment, this was necessary only for a direct convolver stage,
which has been removed:
https://hg.mozilla.org/mozilla-central/rev/e66105937eef190dec073f1b9859e07a0272706b#l4.29
FFT convolver stages pad the buffer to the necessary length in
FFTBlock::PadAndMakeScaledDFT().
MozReview-Commit-ID: LqP1x1hmLOM
--HG--
extra : rebase_source : 622e16140b62ca748a31cbd318f881c617baf17a
We will dispatch decoding tasks in Handle{Audio,Video}Decoded() instead.
See comment 0 for the rationale.
MozReview-Commit-ID: 9trJYoMfzJH
--HG--
extra : rebase_source : 0fae6eda31571d34268f2dba58a8e5f6cf0dadc9
extra : source : 275964a63b741e4ac0258e714f54f43d5cc6ae0b
Following P1, cache suspend status changes will be notified when necessary.
If not, it would be a bug that should be fixed. We shouldn't wallpaper the
issue by calling NotifySuspendedStatusChanged() manually.
MozReview-Commit-ID: 9EbybTiOOIO
--HG--
extra : rebase_source : 299e22c6813f4eeb152c4d8140dc295ff856dc1e
extra : source : 2b18fe0368c6332d0b5c1e044218a26c75314124
Hiroyuki Ikezoe
Wes Kocher
Sebastian Hengst
Gabor Krizsanits
Matthew Gregan
James Cheng
Matt Woodrow
Masayuki Nakano
Brad Werth
Bryce Van Dyk
Bill McCloskey
Jonathan Watt
Sylvestre Ledru
btian
Aryeh Gregor
Makoto Kato
Karl Tomlinson
Xidorn Quan
JW Wang