Ran into a couple of test failures because I was leaving
mAttributes empty for empty things like MergeAttributes, and
only setting mType. Since mType is now redundant though, and
since it's the only use of PrimitiveType, I figured I'd just
remove it entirely.
Depends on D4900
Differential Revision: https://phabricator.services.mozilla.com/D6209
--HG--
extra : moz-landing-system : lando
This replaces the hash map of attributes with a tagged union. In
this case, all filter attributes will be stored in line, with the
exception of some more complex attributes which have an internal
nsTArray of floats. This should help avoid all the hashing and
extra heap allocations.
Depends on D4899
Differential Revision: https://phabricator.services.mozilla.com/D4900
--HG--
extra : moz-landing-system : lando
This is a more conservative optimization for bug 1417699. There's no
reason we need to be copying these everywhere, so let's just go ahead
and implement moves.
Differential Revision: https://phabricator.services.mozilla.com/D4899
--HG--
extra : moz-landing-system : lando
nsIDocument::ResetToURI() resets and set the mDocumentLoadGroup property
even if it is given the same instance. This has caused BlockOnload() to
break on media documents, which calls into there while removing UA Widget.
This patch checks the weak ref before resets it.
Depends on D3841
Differential Revision: https://phabricator.services.mozilla.com/D4484
--HG--
extra : moz-landing-system : lando
Should mStreamLength be > 2^32, we could have overflowed leading to false positive test.
Differential Revision: https://phabricator.services.mozilla.com/D6235
--HG--
extra : moz-landing-system : lando
All but one of the current uses of DEFFILE use `SRCDIR + '/file.def'` to
get a srcdir-relative path anyway, and the other one wants an
objdir-relative path, so using Path makes everything clearer.
This makes it more straightforward to translate the paths for the WSL
build.
When calling resume() on a running AudioContext, there is no need to discard current AudioChannelAgent and then create a new one.
Differential Revision: https://phabricator.services.mozilla.com/D5799
--HG--
extra : moz-landing-system : lando
This reverts the changes in bug 1360308, bug 1390143 and bug 1469603. Minidump
generation will now only happen on the main process' main thread which might
lead to hangs but is known to be fairly robust. Asynchronous generation proved
too brittle and enormously increased the complexity of this already
hard-to-read code.
Differential Revision: https://phabricator.services.mozilla.com/D5147
--HG--
extra : moz-landing-system : lando
We need the isDOMClass() checks in the Compartment code to pass tests, because
some of the jsapi tests explicitly test those failure codepaths. But not with
DOM objects, which is what we're interested in here.
Differential Revision: https://phabricator.services.mozilla.com/D6047
--HG--
extra : moz-landing-system : lando
The next patch would create another subclass of FullscreenChange for
handling fullscreen exit.
Depends on D5988
Differential Revision: https://phabricator.services.mozilla.com/D5989
--HG--
rename : dom/base/FullscreenRequest.h => dom/base/FullscreenChange.h
extra : moz-landing-system : lando
Prior bug 1416085, reads were clamped to the content's duration (if known). It appears that the new code relied on MediaCacheReadBlockFromCache to properly account for the end of content.
However, this was not the case, the MediaCache always reads (and write) one full block at a time regardles of the size requested (a block is 32768 bytes).
Rather than clamping in the Read() method as it used to be, we clamp in ReadBlockFromCache as such safety will benefit other callers that would have otherwise also returned garbage reads.
Differential Revision: https://phabricator.services.mozilla.com/D5964
--HG--
extra : moz-landing-system : lando
The AutoplayPermissionManager might be destroyed before the AutoplayPermissionRequest, so we can't
get the response from request before AutoplayPermissionManager is destroyed.
Therefore, we should manually reject the promise when the inner window is going to be destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D5906
--HG--
extra : moz-landing-system : lando
The reason we hit this assertion is that we still connected to Then() and waited for its result when the resolve or reject
runnable which dispatched by ThenValue can't be executed because the target thread had been shutdown.
Therefore, when XPCOM is going to shutdown, we should disconnect the Then() because it might not have a chance to execute
its resolve/reject method.
Differential Revision: https://phabricator.services.mozilla.com/D5893
--HG--
extra : moz-landing-system : lando
