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
The sNPObjWrappers table can contain entries for dead JSObjects that have not yet been finalised. We need to take care not to trigger mJSObj's read barrier for such entries since that will attempt to expose the object to JS and cause this assertion.
The patch does this by calling unbarrieredGetPtr() which avoids the barrier.
Note converting a TenuredHeap to bool and testing equality against a pointer don't trigger the barrier.
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
https://msdn.microsoft.com/en-us/library/windows/desktop/dd797815(v=vs.85).aspx
Relax the resolution limitation from "width <= 4096 and height <= 2304" to "any width and height combination as long as the total pixel count is under 4096x2304".
MozReview-Commit-ID: 5wHiJfLaJkp
--HG--
extra : rebase_source : 11bf99d0eb3b50ea0199a7f65e0491e43318d29c
This pref does not override privacy.resistFingerprinting, but when it is set (and
privacy.resistFingerprinting is not) we will still adjust the precision of almost
all timers. The adjustment amount is the second pref, which is defaulted to
20us but now dynamically adjustable (in the scale of microseconds.)
This patch does _not_ address the performance API, which privacy.resistFingerprinting
disables.
We are landing this preffed on at the current value we clamp performance.now() at
which is 20us.
MozReview-Commit-ID: ESZlSvH9w1D
--HG--
extra : rebase_source : a8afead1bdba958c6c7b383b2216dacb3a1b135c
Content processes can contain ghost windows, so the debug-only ghost
window unlinker needs to send a message to child processes to get them
to run it, too.
MozReview-Commit-ID: 9Ffc3SDNDJB
--HG--
extra : rebase_source : 875891e9332cf41c4157d246b71c2c361cab4aa6
Includes the build changes made by the earlier patches in this series. Also adds some #includes required by other files when these are added to the unified build.
--HG--
extra : rebase_source : 0a7ea51fe46c2c0c919a03b7dd7cccc637e7b515
extra : histedit_source : a70277a4d8d0b37f983e6d97b8b54d54fba01ba6
Adds Win32 networking APIs to the function broker so that we can run SSL communications outside of the sandbox.
--HG--
extra : rebase_source : 9a5ec38dd9f8a4f1f7bbada461e97513c7db0ab7
extra : histedit_source : f9460155a84f734fa0663bca9f4d18963c07cef5
Moves GetWindowInfo, GetKeyState, SetCursorPos, GetSaveFileNameW and GetOpenFileNameW to the new FunctionHook and FunctionBroker systems.
--HG--
extra : rebase_source : faa4a5a343d3c7c9310241ad361e563a0221d2d7
extra : histedit_source : 1d06fc0480f03506e188efc834e35561bb6b07d1
The FunctionBroker is a special kind of FunctionHook that brokers the hooked function on another process. In the child process, it uses the FunctionBrokerChild to request that the FunctionBrokerParent run a function and return the response. It handles most cases of parameter, return value and error marshaling on its own. It also guarantees that requests are issued from the proper thread.
--HG--
extra : rebase_source : 99e4864f3e6396695eae0ff9aec75aa3c69f082f
The FunctionBroker actors allow the NPAPI process (child) to run methods on the main process (parent). Both the parent and the child run dedicated threads for this task -- this is a top-level protocol.
--HG--
extra : rebase_source : 38c02140f364f32c4ea16cac79d80facf168c2f9
IpdlTuple is an array of Variants that is accessed by type and that reports an error if there is a type error. This is used for safe and easy communication of IPDL objects, validated at run time since IPC data is untrusted.
--HG--
extra : rebase_source : ee113d501d5372cfd01f0be9a58e2db50ab539b3
We have not been initializing or shutting down XPCOM in the plugin process. We need the nsThreadManager for this bug but, more importantly, we need to properly shut down XPCOM in order to get things like handlers connected to the ShutdownPhases (e.g. ClearOnShutdown, used to free resources at process end).
This patch includes some work to make services that are uninitialized in the plugin process to handle Shutdown calls without failing.
--HG--
extra : rebase_source : 837eddd8f8cf956b248c81cb26ca183bf13d1b46
FunctionHook uses the DLL interceptor to redirect Win32 calls to a user-supplied function.
--HG--
extra : rebase_source : 27c2ee94e1f2993bfd871a559b7d45c5bd45e510
webrtc.org only supports one-byte rtp header extensions which means
we can only support 16 character mids for now.
MozReview-Commit-ID: C7aTeB5Bi2M
--HG--
extra : rebase_source : e25518d02fb056f82d298f000e37cfe059099a38
* * *
Bug 1428745 - Remove support for version parameter from script loader - fixing a broken depending test - CLOSED TREE, r=me
* * *
Bug 1428745 - Remove support for version parameter from script loader - fixing WPTs - CLOSED TREE, r=me
* * *
Bug 1428745 - Remove support for version parameter from script loader - fixing tests - CLOSED TREE, r=me
SetState() will delete the current state object and UAF will happen if members
are accessed after this call. However, sometimes it is not obvious if SetState()
is called indirectly as we do in MaybeFinishSeek().
To make it less error-prone, we will keep the old state object alive for a bit
longer and set mMaster to null to catch potential UAF.
MozReview-Commit-ID: Aqxj92ETjti
--HG--
extra : rebase_source : 21b4a0b6df2b1723eed01b6c9d58b33b8dcc6405
Summary:
Add support for PublicKeyCredentialRequestOptions.userVerification. For now
this basically means that we'll abort the operation with NotAllowed, as we
don't support user verification yet.
Pass PublicKeyCredentialDescriptor.transports through to the token manager
implementations. The softoken will ignore those and pretend to support all
transports defined by the spec. The USB HID token will check for the "usb"
transport and either ignore credentials accordingly, or abort the operation.
Note: The `UserVerificationRequirement` in WebIDL is defined at https://w3c.github.io/webauthn/#assertion-options
Reviewers: jcj, smaug
Reviewed By: jcj, smaug
Bug #: 1406467
Differential Revision: https://phabricator.services.mozilla.com/D338
--HG--
extra : amend_source : 314cadb3bc40bbbee2a414bc5f13caed55f9d720
Note we add mClient->CacheClientSuspend() so the network state of the element
is changed to IDLE because we have no channel to fetch data initially.
MozReview-Commit-ID: DgJbMxvJBzH
--HG--
extra : rebase_source : 69a3ef35d4b5faaaa645fabe02246d49aebce22e
extra : source : 61ec40ce378a444ec0f74d474c28b6a9db3aa830
This is required by P2 where we want to notify the 'suspend' event for a cloned
resource whose mChannel is initially null.
MozReview-Commit-ID: 3znDl2TqlqK
--HG--
extra : rebase_source : 71c3d6dc2052566b6bfb0879ce56b804312c5a37
extra : source : e6b7cb7937c80420ad2725c5a77143c7a071150f
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 : bee2d8ae5dedfb88c1bb8fa5cf452014d74afaed
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 : 559af90ba766ebd4deb5d99b6696cd2207215f9f
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 : 788dab679298841fc03bb054458b6f8cc4a0a8d9
