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 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
Otherwise we will seek to a position beyond the duration when exiting dormant
which will fail an assertion in OggDemuxer.
MozReview-Commit-ID: FPWKyd8APrj
--HG--
extra : rebase_source : 89b8cbcfbf9a63d428b9d2a513b2656fc241892f
extra : source : d6a0a81abc7781b6620777ab4cf44222942d78bd
This also changes the function to return a sequence (JS Array) instead of
an nsFontFaceList object, and converts nsFontFace/nsIDOMFontFace into a
Web IDL implemented object too.
MozReview-Commit-ID: 1iAW3DYe5kO
--HG--
rename : layout/inspector/nsFontFace.cpp => layout/inspector/InspectorFontFace.cpp
This is unused in mozilla-central but still used by comm-central.
The only consumer of this API really just wants the URL strings, so
we return a sequence<DOMString> instead of an array of nsIURI objects.
MozReview-Commit-ID: ITcEe42shHw
Margareta Eliza Balazs
Boris Zbarsky
Jeff Gilbert
Ben Kelly
Noemi Erli
Andreea Pavel
Andrew Sutherland
Andrew Osmond
Jon Coppeard
Tom Ritter
bechen@mozilla.com
Sylvestre Ledru
Ciure Andrei
JW Wang
Cameron McCormack