The test change is needed because there is no notok() function. But the old
nsIDOMEventListener setup would fail to report the exception anywhere, so the
test still passed (albeit without testing what it thought it was testing). The
new setup reports the exception via an error event on the window, and the test
harness notices that.
MozReview-Commit-ID: 3ISmcyhMk0R
BarProp, CaretPosition, Crypto, CSSMozDocumentRule, CSSPrimitiveValue,
CSSStyleDeclaration, CSSStyleRule, CSSValueList, DOMImplementation,
DOMTokenList, FileList, FrameLoader, FormData, HTMLCollection, History,
MimeTypeArray, NamedNodeMap, MutationObserver, MutationRecord, Navigator,
NodeIterator, PaintRequest, PaintRequestList, Plugin, Rect,
SVGAnimatedEnumeration, SVGAnimatedInteger, SVGAnimatedNumber,
SVGAnimatedNumberList, SVGAnimatedPreserveAspectRatio, SVGAnimatedString,
SVGLengthList, SVGNumberList, SVGPathSegList, SVGPoint, SVGPointList,
SVGPreserveAspectRatio, SVGRect, SVGStringList, SVGTransformList, Touch,
TouchList, TreeWalker, ValidityState only implement nsISupports, so
there's no point QIing them.
DOMStringMap, FrameLoader, NodeIterator, SVGPoint, StyleSheet only implement
non-scriptable non-shimmed interfaces (nsIMutationObserver, nsISVGPoint,
nsICSSLoaderObserver), so can't be usefully QIed from script.
EventSource, Notification, OfflineResourceList, Performance, Screen,
WebSocket, XMLHttpRequestUpload only implement nsIDOMEventTarget, and nothing
QIs to that in script.
PluginArray QIs to nsIObserver but doesn't expose any corresponding methods.
None of the QIs to that interface seem to be on PluginArray objects.
Range QIs to nsIDOMRange, but there is no JS code that QIs to that.
NodeList QIs to nsIDOMNodeList, but there is no JS code that QIs to that.
XMLSerializer doesn't even implement nsISupports.
MozReview-Commit-ID: Fil5cBd4K4d
We could have used the new NS_NewCStringInputStream overload here, but
it seemed nicer to directly transfer ownership into the newly-created
stream. If we're going to be more efficient here, we might as well go
as far as when can without making the code too ugly.
The XXX comment here wants to give up the string data when we create the
outgoing stream. Giving up the string data is legitimate, because
GetEncodedSubmission is the last operation to be called on this object;
mQueryString is effectively dead after this function returns.
Accordingly, we can Move() mQueryString into the outgoing stream for a
nice efficiency boost.
Per spec, assinging an empty string to textContent or innerHTML should not
trigger any mutation observers, and therefore should not trigger a stylesheet
reparse, when the element is already empty.
Since we need to apply some special handling to innerHTML and textContent
assignments to <style> nodes, and therefore re-parse directly in the setter
rather than in response to mutation observers, we need to special-case this
scenario.
MozReview-Commit-ID: KdOYFs8ayT7
--HG--
extra : rebase_source : 67b85174d08028c5200964800b657950aa2bffa2
This will make it possible to migrate existing bindings without also needing to
mass-rewrite frontend code at the same time.
MozReview-Commit-ID: IBBqC4eeDDX
--HG--
extra : rebase_source : e901ac665208b3a683668c1bb33a26dcf479580c
Animation::FlushStyle() gets called only for CSS animations/transitions'
playState changes in JS or ready Promise for CSS animations. In either case
throttled animation state, which is, to be precise, transformed position or
opacity value on the compositor, doesn't affect those results.
The first test case for CSS animations and the first test case for CSS
transitions in this patch fail without this fix.
MozReview-Commit-ID: EVym4qputL4
--HG--
extra : rebase_source : 12524c7db1d59da69687bb123fc65ad4301f5527
The old code would ignore mThresholds if we happened to update when the
observed element was edge-adjacent to its root. This could cause spurious
notifications if it happened to run during a CSS transformation. The new code
more closely follows the spec with a slight deviation where the code treats
all values less than the smallest passed-in threshold as equivalent (when
looking at previousIndex). This matches Chrome's implementation and the tests.
MozReview-Commit-ID: 7oAh1EdjMiY
--HG--
extra : rebase_source : 46de4aee9c7da36bd1b41c07fa9b6bbe8ee15dc0
We need to side-step existing cross-origin checks in Performance Timing code
when the caller is a web extension content script that otherwise has permission
to access the cross-origin resource.
MozReview-Commit-ID: 8IgtqZgPWgY
--HG--
extra : rebase_source : e8152c5d8ab32096d1ff7f97311c1b43b57c3694
This patch was reviewed in parts, however the intermediate states would not build:
Bug 1443954 - Part 3A: Strip pointers from the argument to WriteParam and WriteIPDLParam before selecting the ParamTraits impl, r=froydnj
Bug 1443954 - Part 3B: Move nsIAlertNotification serialization to the refcounted system, r=bz
Bug 1443954 - Part 3C: Move geolocation serialization to the refcounted system, r=bz
Bug 1443954 - Part 3D: Move nsIInputStream serialization to the refcounted system, r=baku
Bug 1443954 - Part 3E: Move BlobImpl serialization to the refcounted system, r=baku
Bug 1443954 - Part 3F: Correctly implement ParamTraits for actors after the ParamTraits changes, r=froydnj
Test various writing mode combinations of a scrolling target and its root,
including the methods of honouring both the target and its root.
MozReview-Commit-ID: 3QmvRz45VmW
--HG--
extra : rebase_source : 55480cfe9d9d8de96b3295d301edd0615e1381db
This method is not a virtual call, and also looks nicer.
This patch was mostly generated by a Python script, but I manually
cleaned up the code in a few places where statements didn't need to be
split across multiple lines any more.
MozReview-Commit-ID: 8JExxqSRc59
--HG--
extra : rebase_source : df6330a89e8d65dfe7a6fda0c8cb9f9732302efc
We should not use LoadLibraryA (or more generally "A" functions) on Windows
because it is lossy. Bug 1440886 will introduce a static analysis to prevent
potential misuse of LoadLibraryA, so we need to replace existing usages first.
MozReview-Commit-ID: 6krgrVcSHNW
--HG--
extra : rebase_source : 0e93acecfe0c9ccd2e4ba9ad3126b6ae16433387
And a builtin function to test if wasm gc is enabled or not, to make testing
easier.
--HG--
extra : rebase_source : 0e608756d0c5f0231ba31af482c5e343a7119465
The documentation says that the boolean return values from these methods
must be checked. We might as well make the compiler check these things
for us.
With this commit, all the auto-dir scrolling functionalities are completed in
non-APZ.
MozReview-Commit-ID: 9v9iPWIwB52
--HG--
extra : rebase_source : 9c825ed6ebcd84a90057bcb9d301838014c181d8
This commit implements the auto-dir scrolling functionality in non-APZ, based on
part 1 to part 3. However, the functionality of mousewheel.autodir.honourroot is
unimplemented in this commit.
MozReview-Commit-ID: 2vYABOx4RkK
--HG--
extra : rebase_source : 7dc45e6747a101c1a2c3a22bc695b2a0b2494b50
This commit implements the auto-dir scrolling functionality in APZ, based on
part 1 to part 3. However, the functionality of mousewheel.autodir.honourroot
will be implemented in a future.
MozReview-Commit-ID: 9xai99x71gh
--HG--
extra : rebase_source : 118d188f730e3fb91d147b076a053cb04e622e55
This commit defines a common interface of the auto-dir scrolling functionality.
In future commits, it will be implemented in both the APZ and non-APZ parts.
MozReview-Commit-ID: 8fApuHwsbrv
--HG--
extra : rebase_source : e4c47ea52c1c9c60822b23216db020154522bb7e
This commit only introduces the concept and the functionality of retrieving the
values from the two new related prefs. Still no actual functionality change is
involved.
MozReview-Commit-ID: 2Gl3Wqdo6jL
--HG--
extra : rebase_source : bf30483e3e32829a5d6fd927740471ba348448f9
Do some work in preparation for implementing actual functionalities for this
bug. No actual functionality change is involved in this commit.
MozReview-Commit-ID: 5aLhr38n1N4
--HG--
extra : rebase_source : 15cfc2cea5b7668367dd3bd4a0746ae8c61b7d20
Also ensure that the MP4 demuxer can't create such sample.
MozReview-Commit-ID: JANgHNiiz2H
--HG--
extra : rebase_source : d6a68579e76f1eda651e38bec5a9ed17c9de3fa4
nsIPrincipal is not yet threadsafe (bug 1443925). This is a problem in the context of threadsafe nsIURI, where cloning an nsIURI would also AddRef the principal.
To get around this problem, we use nsMainThreadPtrHandle<nsIPrincipal>. This means cloning the URI would not AddRef the principal (it addrefs the nsMainThreadPtrHolder that holds the principal). When the last ref is dropped, the principal is released on the main thread.
We should get rid of this once principals become thread-safe
MozReview-Commit-ID: AbJEhTNXVv6
--HG--
extra : rebase_source : 14808be2815aaeb2f017fc04d28aa03b9f4bbcd5
We weren't checking the length of our buttons array before referencing
dpad offsets, meaning if the HID descriptor reports something
different than we have, we can overflow.
MozReview-Commit-ID: 5RKxwDmmq0Z
--HG--
extra : rebase_source : afbe0aff9c89b8ded57462384f0bf4158facdbd9
We don't want to skip all remaining steps. For now it just affects some logging,
but there may be new ones added in the future.
MozReview-Commit-ID: 7fBdgLNT780
--HG--
extra : rebase_source : dc5113298c1dbadd23c19127349a4a66cd460b4c
clang-tidy suggestions in "part 3 - Console API exposed to worklets".
MozReview-Commit-ID: Aab74PCau9m
--HG--
extra : rebase_source : 0f4a5500e391ee734c3e5fcc0c7930007310de27
I'm not aware of any reason why SourceBufferHolder must be allocated only on
the stack, but bz and bkelly seemed to agree that it should be MOZ_STACK_CLASS
in https://bugzilla.mozilla.org/show_bug.cgi?id=987556#c72
FWIW avoiding SourceBufferHolder saves by not needing to store GiveOwnership.
UniquePtr makes the transfer of ownership clearer.
MozReview-Commit-ID: 2wxkW75TNUM
--HG--
extra : rebase_source : 86b47023f252fd9f009be530d5ada8d6e82499e9
Initial version r=smaug.
Rebased to c616a6fd5e4b by Jan-Ivar Bruaroey <jib@mozilla.com> r=karlt.
Rebased to 83de58ddda20 by Karl Tomlinson <karlt+@karlt.net> r=baku.
MozReview-Commit-ID: G5E5OXydj3a
--HG--
extra : rebase_source : 4c6c9d396debce92299496c86bb6f55fbbb15a8a
Initial version r=smaug.
Rebased to c616a6fd5e4b by Jan-Ivar Bruaroey <jib@mozilla.com> r=karlt.
Rebased to 83de58ddda20 by Karl Tomlinson <karlt+@karlt.net> r=baku.
MozReview-Commit-ID: Lo8TWtN8qyz
--HG--
extra : rebase_source : ffcb7b835ea49cda3e25dfa94a91b3725fdbfb29
postMessage doesn't really have different origins for file: URIs;
to send to them you need "*", and `location.origin` is null. So
testing jar:file separately doesn't seem to make much sense, so
let's just remove the test now that jar: will only really be
usable with a local/file inner URI.
MozReview-Commit-ID: 7vvlrugi3xv
--HG--
extra : rebase_source : 3b31b817da3922c30691654ae49ab3c9130e6b36
Bug 1063538 was reported with a testcase that accesses a .jsp, which
in turn sleeps "forever". The testcase seems to be simulating this by
using a jar:http: URI for a really big file contained in some other
directory.
Instead, we can just use a .sjs file that does a similar thing to the
original jsp file in the reporter's testcase, which conveniently also
allows us to remove dependencies on support files in other directories.
MozReview-Commit-ID: 2JCOS9VLgVv
--HG--
extra : rebase_source : d0cbc4e149b8ef872e12680071bf2b1227bfb925
postMessage doesn't really have different origins for file: URIs;
to send to them you need "*", and `location.origin` is null. So
testing jar:file separately doesn't seem to make much sense, so
let's just remove the test now that jar: will only really be
usable with a local/file inner URI.
MozReview-Commit-ID: 7vvlrugi3xv
--HG--
extra : rebase_source : cfa701fd5fa03bf8d03a2bd773ec908a26020944
Bug 1063538 was reported with a testcase that accesses a .jsp, which
in turn sleeps "forever". The testcase seems to be simulating this by
using a jar:http: URI for a really big file contained in some other
directory.
Instead, we can just use a .sjs file that does a similar thing to the
original jsp file in the reporter's testcase, which conveniently also
allows us to remove dependencies on support files in other directories.
MozReview-Commit-ID: 2JCOS9VLgVv
--HG--
extra : rebase_source : 90245a05d197c9578d0b5278a247216c95f48c68
Test that play() on a media without audio called before
readyState >= HAVE_METADATA will still play.
MozReview-Commit-ID: 1FeDrEfCEum
--HG--
extra : rebase_source : be6d07905aad853ad028eac372e4e380bdeb1a49
extra : source : e98b4a7aaf020fa3d6d59cb0f53680ef6466d154
We want to block playback of media which have an audio track, so if play()
is called before the load of the resource has loaded metadata, we need to
delay starting playback and resolving the play promise until we've figured
out whether the media has audio. So if play() is called before we've reached
readyState >= HAVE_METADATA, set a flag, and check that flag when we do
reach HAVE_METADATA and start the play and resolve the promise then.
MozReview-Commit-ID: 1K06NK2kfpw
--HG--
extra : rebase_source : 45636e77b44ed072e1bc3f1e9a9f73f206ee04de
We have code in the MDSM to toggle on high resolution timers on Windows when we
start/stop playing because the VideoSink relies on being awoken by timers to
update the set of current frames in the compositor's queue, and on Windows 7 we
end up dropping frames due to the timer lag without this.
We assert in the MDSM's destructor that we've turned off high res timers (as
they cause needless battery drain, so we only want them on when we need them),
and the new test_mediarecorder_principals is hitting that assert on Windows. I
think we're missing turning them off when we create a new VideoSink for
outputting to the MSG. That affects the value returned by
MediaDecoderStateMachine->mVideoSink->IsPlaying(), which is what we use to
decide whether we should enable high resolution timers. We track whether we've
enabled high res timers in MDSM::mHiResTimersRequested, and that gets out of
sync with IsPlaying() when we re-create the MediaSink.
Rather than trying to handle all the permutations of places where we need to
turn off high resolution timers in the MDSM, we're better to move the code to
toggle high res timers into the VideoSink, as that's actually where we need to
be sure that we have high resolution timers enabled anyway. It's the VideoSink
after all that is relying on timers for frame update, not the MDSM.
Also remove the media.hi-res-timers.enabled pref, as we haven't needed it.
MozReview-Commit-ID: 9dNxcYxPDZH
--HG--
extra : rebase_source : 6e403d59bb5f1dd0241fe8298a823ba08b1670fb
I changed this test earlier in this set of commits to use
midflight-redirect.sjs so that we get more reliable and predictable cross
origin redirects during the download. Unfortunately this test now times out on
Windows.
This test times out on Windows because midflight-redirect.sjs redirects at 1/4
through the resource, whereas this test expects to be able to play through to
1/5 through the resource, and on Windows that seems to be not reached during
playback. This is likely due to decode latency being higher on Windows.
On top of that, the test's first case can sometimes call MediaRecorder.start()
before the redirect has happened, and before the principal has changed, and so
start() doesn't throw a SecurityError as expected, and the test intermittently
fails.
Additionally, the test's code could be clearer if we used async/await.
So rewrite the test to use async/await, and take advantage of
midflight-redirect.sjs's redirect being more predictable than the old
dynamic_redirect.sjs. Basically, we can be careful to wait for either
"loadedmetadata" or "error" on the media element in order to be more confident
the redirect has or hasn't happened yet.
We still can't be 100% sure that the redirect won't have already happened by
the time our "loadedmetadata" handlers run. It's quite possible that the
download has reached 1/4 through the resource by the time the loadedmetadata
handler has run, so we need to handle the "error" and "loadedmetadata" events
racing.
MozReview-Commit-ID: 8plMjkXgjYt
--HG--
extra : rebase_source : 7305598f40c09219494f3e7150799d8875b7c30e
I'm seeing intermittent failures of test_midflight_redirect_blocked. In this
test, our custom server responds to Firefox's 0- HTTP Byte Range request with a
[0,200] response. When Firefox requests 200-, the server responds with a cross
origin redirect, and then the remainder of the resource.
However sometimes while running test_midflight_redirect_blocked the MP4 demuxer
reads through all 200 bytes while trying to parse metadata before the redirect
has occurred and fed more data into the cache, and so the demuxer thinks it's
hit end of stream, and reports a failure. The demuxer thinks it's hit end of
stream, because we initialize the MediaCacheStream length in
ChannelMediaResource::Open() with the value of the Content-Length HTTP header.
But in an HTTP byte range response, the Content-Length header tells you the
length of the range returned, not the length of the entire resource. The length
of the resource is in the Content-Range header, we need to use that if
available.
So to fix this intermittent test failure, we need to also parse the
Content-Range header in ChannelMediaResource::Open(), and use the length from
that if available.
MozReview-Commit-ID: 29pPRsUvxag
--HG--
extra : rebase_source : ba1ef03d65ebd22698a29d8385f36b4c747ccf43
Problems here:
* The variable `to` is undefined for byte range requests to the end of
the resource, making the math fail. Firefox normally makes ranges requests like
this.
* The bytes.length/4 calculation may not be a whole number, so can
result in a byte range header part of the way between two bytes. We need to
round the length off.
* Instead of re-calculating the contentLength, we can just use the length of
the actual byterange substring being returned. That's clearer.
* test_midflight_redirect_blocked needs the redirect to happen
before metadata has completed loading, but other tests require the redirect to
happen *after* metadata is loaded. So add a redirectAt query parameter for the
requester to control when to redirect.
MozReview-Commit-ID: I6n1NqK0Uze
--HG--
extra : rebase_source : a6bd68fe75cfd4c46f63ca815c5a4e9390bd671a
We have two SJS files; midflight-redirect.sjs and dynamic_redirect.sjs,
which are very similar, but dynamic_redirect.sjs is buggy, so we should
just use midflight-redirect.sjs.
dynamic_redirect.sjs is buggy because it relies on the client doing multiple
HTTP requests to it in order to redirect, but we can't actually guarantee
this. Previously users of it would try things like setting a small MediaCache
size, or only using Ogg for which we expect a seek to the end to calculate
the duration, but I have observed the entire resource being downloaded in
one hit before the media element has finished loading metadata, meaning the
seek (in the Ogg case) can happen without another HTTP request. This is even
with a small MediaCache.
midfligh-redirect.sjs solves this problem by explicitly only returning a
partial response, so the client is forced to make another HTTP request,
which we will serve a redirect to.
MozReview-Commit-ID: 39imyayhnBG
--HG--
extra : rebase_source : 603532e4af0bf304c34739de5b0b243174e3831d
The original test is failing, as it assumed we'd not error when
origins were mixed without CORS, and the original test was using
outdated practises, so rewrite it.
MozReview-Commit-ID: KlOH83GUOk
--HG--
extra : rebase_source : 2c79691fddc93af0e04d8f23fa31ac8588a8d6e1
extra : amend_source : 2989317530f536915f011977c8f34e048410b018
Try to prevent Necko from caching the results of our SJS media responses, as
some of the test that use it rely on the server being hit and serving a
redirect. Sometimes the tests which rely on hitting a redirect in an SJS
where timing out without this, as Necko would cache the response and not
hit the server, and so not hit the redirect.
Also include a noise parameter to increase the likelihood that the URL is
unique, to further reduce the chance that Necko caches the result.
MozReview-Commit-ID: 3cLEiDoh4HG
--HG--
extra : rebase_source : 24c152d46540866f14211fae30f1e59c5d23b6d4
dynamic_redirect.sjs and midflight-redirect.sjs are serving files
with "Content-Type: video/ogg", which is incorrect and could lead
to problems given that we're not always asking it to serve Ogg
files. So include the type be to served as a query parameter.
MozReview-Commit-ID: 5f0PXy8lL3G
--HG--
extra : rebase_source : 757395a21317655422767efe3f7c1923a19c0114
Test that playback works if we don't block, doesn't if we do block, and does
if we do block and CORS is used.
MozReview-Commit-ID: 9PTZXLOdHIU
--HG--
extra : rebase_source : db7f0c61b64990623ef035b266cf052c45df1c76
There's no compelling use case for mid-flight redirects, and Chrome
already blocks it, so there's little point in maintaining it.
Add a hidden pref to toggle blocking, so we can toggle it off during
testing to ensure that we're blocking a working mid-flight redirect.
MozReview-Commit-ID: EnGNmYFr8Uv
--HG--
extra : rebase_source : a2f4b7c68b73ecc4c7525d4e41e834f4caf85707
These are unused in C++, and the JS bits don't go through this interface
(instead they end up calling things off the relevant XBL prototypes by finding
them on the node's proto chain).
MozReview-Commit-ID: 4FTyFCl4DRt
Because the shutdown closure awaits finishing itself by
TaskQueue::AwaitShutdownAndIdle(), the function blocks infinitely.
The code is wrongly introduced at the following commit:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1319987
* https://hg.mozilla.org/mozilla-central/rev/b2171e3e8b69
This patch calls it on mTaskQueue intead of mOmxTaskQueue to
avoid the issue.
MozReview-Commit-ID: 4qmX2QlniEG
--HG--
extra : rebase_source : f0784c0c5b2e39d2078a5aff72be03b52e413139
extra : intermediate-source : 635153e1dcdc442f8d72727b6fe504842b4ffa31
extra : source : bf011140459cc227c9435e3960770bafb3cecb8e
It's a concrete class of OmxPlatformLayer for accessing OpenMAX IL
libraries directly. It will be usable on various embedded linux systems.
Note that it's not enabled by default yet. Add the following config to
your mozconfig.
ac_add_options --enable-openmax
TODO: Implement zero-copy mode
MozReview-Commit-ID: EMEXAKzzR64
--HG--
extra : rebase_source : d7c5b9baf66d87db38723b278c57fd581a3cbf98
extra : intermediate-source : b8c671a02a4fce085433b16db998c9b04ace87db
extra : source : 131b65580e3dd5c9dcb0ba6a05c16ab90c2dcc68
Note that on the new style system (a.k.a stylo) the test case hasn't caused
any assertions.
MozReview-Commit-ID: AALHnuW48Rb
--HG--
extra : rebase_source : 8253507eff2522bcc4ccc155aae5c1307a81421d
This is mostly code removal, changing GetDisplayContentsStyle(..) checks by an
FFI call to Servo.
The tricky parts are:
* MaybeCreateLazily, which I fixed to avoid setting bits under display: none
stuff. This was a pre-existing problem, which was wallpapered by the
sc->IsInDisplayNoneSubtree() check, which effectively made the whole
assertion useless (see bug 1381017 for the only crashtest that hit this
though).
* ContentRemoved, where we can no longer know for sure whether the element is
actually display: contents if we're removing it as a response to a style
change. See the comment there. That kinda sucks, but that case is relatively
weird, and it's better than adding tons of complexity to handle that.
* GetParentComputedStyle, which also has a comment there. Also, this function
has only one caller now, so we should maybe try to remove it.
The different assertions after DestroyFramesForAndRestyle are changed for a
single assertion in the function itself, and the node bit used as an
optimization to avoid hashtable lookups is taken back.
MozReview-Commit-ID: AZm822QnhF9
HookProtectedMode requires its nsWindowsDllInterceptor to last as long as the functions need to be overridden. This uses a static object instead of a local one.
--HG--
extra : rebase_source : 7ba3f2fc1e19f89936b7f7fa490554e9cf9b885c
Original patch by Ethan Lin <ethlin@mozilla.com>.
MozReview-Commit-ID: AAIaskIsz9x
--HG--
extra : rebase_source : 879144b98467f47867d66f2806d7d31dbcf2bc7b
This removes properties of XULElement that can easily seen to be unused, even if the attributes they control are still in use. There are other properties that may still be used once or twice, and they are not removed here.
MozReview-Commit-ID: IL6mCvtGQAG
--HG--
extra : rebase_source : 4b22b330d311ef22e3466f517c04d5a19512ab71
The flag was introduced in bug 1322291 to prevent recursive calls of
KeyframeEffectReadOnly::ComposeStyle() on the old style system. On the
new style system we never call the function recursively.
MozReview-Commit-ID: L5gb8G3bl4M
--HG--
extra : rebase_source : 3b01c2c3ff97b8890bf13095dd32b834270d00df
This covers all the reftests that have lower fuzz (or zero fuzz) and
were producing an UNEXPECTED-PASS result with webrender on windows. In
many cases I just adjusted the lower bound of the existing webrender
fuzz. In other cases existing fails-if conditions had to be tweaked to
exclude webrender.
MozReview-Commit-ID: 49LvS0vuYWR
--HG--
extra : rebase_source : d194e24affb87fe4560a127ff4016f9c38f414fd
Cleanup of all localization notes that refer to entities
that are not listed in the corresponding localization file.
MozReview-Commit-ID: Bl0VU9HoPfa
--HG--
extra : rebase_source : 86680b8ae037783304f045e94c7af7053a0f69e9
This creates a simulcast stream with an odd resolution. This previously would
have caused a runtime assertion failure and crash.
MozReview-Commit-ID: IsywVOu6UeV
--HG--
extra : rebase_source : 7ad1cbe7dd36ccdd7a05e0c0a83db98a36c8c416
The security checks outer window did here don't seem right, because the whole
point is that this method is only called by C++ code for its own purposes.
We're not adding random untrusted listeners via addSystemEventListener!
MozReview-Commit-ID: JdS5gTESclu
The CanCallerAccess check in the "webidl" version of
nsGlobalWindowOuter::AddEventListener was pointless, because bindings never
call things on outer windows.
MozReview-Commit-ID: 1CGMJ277bPu
Also switch the XPCOM-y version of EventTarget::AddEventListner to a
Nullable<bool> for aWantsUntrusted.
The three-arg overload of AddEventListener in ContentFrameMessageManager was
never called, so all the AddEventListener overloads there are not needed.
MozReview-Commit-ID: 4IhqHmPVWzE
Coroiu Cristina
Ryan VanderMeulen
Bob Owen
Gurzau Raul
Cameron McCormack
Boris Zbarsky
Tristan Bourvon
Nathan Froyd
Bryce Van Dyk
Kris Maglione
Ben Kelly
Brian Grinstead
Hiroyuki Ikezoe
Blake Kaplan
Tomislav Jovanovic
Jeff Walden
arthur.iakab
Nika Layzell
Vinothkumar Nagasayanan
Dan Minor
Gijs Kruitbosch
Andreea Pavel
Andreas Pehrson
Catalin Badea
Christoph Kerschbaumer
Margareta Eliza Balazs
Nicholas Nethercote
Andrea Marchesini
Zhang Junzhi
Tom Ritter
Andrew McCreight
Masatoshi Kimura
Emilio Cobos Álvarez
Tom Bannister
Benjamin Bouvier
Nathan Froyd
Jon Coppeard
Kartikaya Gupta
Jean-Yves Avenard
Valentin Gosu
Kyle Machulis
Byron Campen [:bwc]
Karl Tomlinson
Ciure Andrei
Alex Chronopoulos
Kate McKinley
Tom Schuster
Csoregi Natalia
Chris Pearce
Tooru Fujisawa
Alex Gaynor
Stephen A Pohl
Olli Pettay
Noemi Erli
Jonathan Watt
Takuro Ashie
Brindusan Cristian
Nils Ohlmeier [:drno]
Adrian Wielgosik
Bobby Holley
David Parks
Nicolas B. Pierron
Adam Gashlin
Paolo Amadini
Doug Thayer
Julian Descottes
Randell Jesup