The spec changed in order to align with the error thrown by importNode.
--HG--
rename : dom/tests/mochitest/webcomponents/test_bug1176757.html => dom/tests/mochitest/webcomponents/test_shadowroot_clonenode.html
In order to write tests, I would like to create an method that allows chorome js can directly set the user-activation flag.
Therefore, I need to move all these details into nsDocument, then we could easily simulate the user activation.
MozReview-Commit-ID: 5JrCoQc0vF7
--HG--
extra : rebase_source : 256ff2993ef754dc51409e7e444b868a3302bd65
For top level frame, it should also be activated when user activate its child frame.
eg. A (youtube.com) -> B (ad.com), when user activate B frame, the A frame would also be activated.
MozReview-Commit-ID: BP7eGKiqYJe
--HG--
extra : rebase_source : 8a07e2a46d70957989168a9ee677e5241fee61fe
This was used in CGPrototypeTraitsClass, but that usage was removed at
some point.
MozReview-Commit-ID: G3bGMma5XTw
--HG--
extra : rebase_source : 89ff19e10bba68a8e3e3392d3695448dfb245d7c
Also, expects onmute to happen before SRD resolves, even for offers.
MozReview-Commit-ID: 2ibQKDfyHYH
--HG--
extra : rebase_source : c47533d173ae13b851e585158811118047968a19
extra : intermediate-source : ab30f91e677aece43bd5049ac0e3725a0793328e
extra : source : bee557f078c402c7893c19ca1dc3bc2164261e65
Remove the probe, and remove the cached value check.
Also remove dead code which relies on this sometimes-clamping glGet query.
MozReview-Commit-ID: JA1VgH8fLRB
This patch reflects the following change to the Web Animations spec:
abf76745b5
MozReview-Commit-ID: A2GD1igUf5f
--HG--
extra : rebase_source : 8129f6386b144adebc3bf0320ca7d6bfbba7a2e9
This test is unfortunately a victim of a multi-e10s unregister() race
from browser_force_refresh and given the imminent multi-e10s cleanup
that's going to happen, the more complicated alternatives aren't worth
the effort versus just moving this test to its own directory.
..and now it's disabled too. Bug 1429794 tracks re-enabling.
--HG--
rename : dom/workers/test/serviceworkers/browser_multie10s_update.js => dom/workers/test/serviceworkers/isolated/multi-e10s-update/browser_multie10s_update.js
rename : dom/workers/test/serviceworkers/file_multie10s_update.html => dom/workers/test/serviceworkers/isolated/multi-e10s-update/file_multie10s_update.html
rename : dom/workers/test/serviceworkers/server_multie10s_update.sjs => dom/workers/test/serviceworkers/isolated/multi-e10s-update/server_multie10s_update.sjs
extra : rebase_source : 2f93eda70120fff7f5b8ebac3db1f46c3aaf3070
extra : source : 3f059dbbf8ba6d42984a4a8c08836aec3ae37f47
This test used a fixed setTimeout of 3secs for serving the SW. This
lower-bounded the test runtime at 6 seconds, plus it was not safe in
the event of a slow test runner.
This set of changes, although a little ugly, improves the logic so that
the SW's transmission is driven by a separate "release" fetch that is
only triggered when both updates have been issued and the first update
failure has been reported. This ensures we are observing the desired
situation. There's also a sanity check on the number of times the SW
script is fetched.
--HG--
extra : rebase_source : 895af5a50578ca69ce9437b67fa0590c1f046682
extra : source : e708703ab4459ccba7a5242a6a50df4a47b59175
This adds a test where we have a ServiceWorker return 2 different types
of streams that Firefox recognizes as downloads which are handled by
diversion of the channel to the parent. The diverted downloads are
then cancelled and we verify that cancellation actually results in the
underlying connections being closed and/or the ServiceWorker notified.
Our 2 types of streams are:
1. A pass-through stream that is incrementally delivered through use of
an .sjs file that delivers data using setInterval.
2. A SW-authored ReadableStream (which is not enabled by default, so we
set a pref.)
Determining when the .sjs's stream is canceled is accomplished by
opening a second "monitor" connection that only completes when the
streaming connection is closed.
In all cases we differentiate between cancelation and timeouts firing.
--HG--
extra : rebase_source : 255ea1b97d632363d7465d6d116a8c37dcca85c3
extra : source : 840a6e04bcea7d87e362adf14a37b7c17e20f043
Currently, FetchStreamReader never signals to the JS stream code that
the reader has been closed. This means that when a ServiceWorker
passes a ReadableStream to respondWith and the HTTP Channel gets
canceled, the JS code will keep generating the stream without ever
realizing the data's not going anywhere. It's necessary to cancel
the reader. Or do something like that, this seems to work!
--HG--
extra : rebase_source : 88952a917c48b9fa7e421f640b7fb57b15cf7d4d
extra : source : 994dc643a2ab62f03fef780a58971b476a4b6f4a
In the scenario where a ServiceWorker returns a pass-through fetch via
`evt.respondWith(fetch("underlying"))`, in order for the "underlying"
HTTP channel to be canceled when the outer HTTP channel is canceled,
FetchDriver's OnDataAvailable method needs to return an error when
the output pipe experiences an error.
Unfortunately, the contract for ReadSegments is effectively that it
returns NS_OK regardless of what the rv of the write handler returned,
so relying on the returned rv is insufficient. And because various
Write*() methods will all fast-path to returning NS_OK if a count of 0
is passed, it's necessary to infer a closed/broken pipe by noticing
that we tried to write more than 0 bytes of data but 0 bytes were
written. (This is safe because the pipe we write into was created
by FetchDriver::OnStartRequest which explicitly creates an infinite
pipe, so it's not possible for the write to fail due to lack of space
in the pipe.)
--HG--
extra : rebase_source : 0a1f9f7a4c244934ff255a07e78608c8ea6fef0e
extra : source : 8e4fd74e7f5e69df7363bdb560f79dde347ce082
