The call in VRFrameData::LazyCreateMatrix is not needed because
aRetval.set(aArray) ends up calling into Heap::get() which does a read barrier
and exposes.
The call in nsXULPrototypeScript::Compile is not needed because initializing
the AutoJSAPI will guarantee that the global of the Realm it enters, which is
what we're examining here, will be exposed.
The call in Promise's CreateNativeHandlerFunction is not needed because the
object being passed in was always just-created into a stack Rooted.
The call in MIDIMessageEvent::GetData is not needed because it's always working
with a just-created object. Also, mData is a Heap, so there will be a read
barrier anyway before anyone gets at the value.
The call in PrototypeDocumentContentSink::ExecuteScript is not needed because
the AutoEntryScript will guarantee that the global of the Realm it enters is
exposed. And the JSAutoRealm is not needed either, because we're in that Realm
already.
Differential Revision: https://phabricator.services.mozilla.com/D29720
--HG--
extra : moz-landing-system : lando
Promise::Compartment is unused.
The callers that want to call AutoJSAPI::Init can pass it an nsIGlobalObject,
which is actually _more_ efficient, since passing a JSObject just gets an
nsIGlobalObject from it and passes that.
Differential Revision: https://phabricator.services.mozilla.com/D29703
--HG--
extra : moz-landing-system : lando
This is split from the previous changeset since if we include dom/ the file size is too
large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27457
--HG--
extra : moz-landing-system : lando
I'm a bit torn between the const-member-and-MOZ_KnownLive approach
here and just taking extra stack refs...
Differential Revision: https://phabricator.services.mozilla.com/D23778
--HG--
extra : moz-landing-system : lando
We don't want extension protocol load requests to begin loading until the
extension is far enough initialized to run code. If we load it before then,
the extension framework will either fail to recognize the extension entirely,
or may begin running its scripts in an incomplete environment.
This patch adds a slow path which adds a promise handler and creats a stub
channel only in the case when the extension is not ready. In the normal,
already-initialized case, we take the more direct path.
Differential Revision: https://phabricator.services.mozilla.com/D21447
--HG--
extra : rebase_source : ca770d241ff68192716feace67cd512565ae6b24
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
With same-compartment chrome globals these would end up in the same compartment.
We need to prevent that because the debugger doesn't support it.
Differential Revision: https://phabricator.services.mozilla.com/D15093
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13073
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13073
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13073
--HG--
extra : moz-landing-system : lando
For reasions which are unclear, MSVC does not recognize the declaration and
definition of ThenWithCycleCollectedArts as matching in their previous form.
Changing both to use the same template `using` declaration for the entire
return type fixes this.
MSVC also has problems with the previous use of std::forward, which is fixed
by explicitly coercing smart pointers to their equivalent pointer types, and
moving any other type.
Differential Revision: https://phabricator.services.mozilla.com/D4397
--HG--
extra : rebase_source : 483fc7c33a0b10227b11862d176299813466ac95
This makes it easier to add promise handlers from C++ in a manner similar to
JavaScript.
Differential Revision: https://phabricator.services.mozilla.com/D3692
--HG--
extra : rebase_source : efa6735da4b22677b684ae790aede6aac6bb1bad
Remove unused PromiseWindowProxy code and nsGlobalWindowInner::AddPendingPromise and nsGlobalWindowInner::RemovePendingPromise
Differential Revision: https://phabricator.services.mozilla.com/D2621
--HG--
extra : moz-landing-system : lando
This allows move semantics when resolving Promises
MozReview-Commit-ID: EYFd3Abr7Ec
--HG--
extra : rebase_source : e4553f3a5a9298d98ca454d98ca4158097b46efd
Olli Pettay
Victor Porof
Alec Gibson
Brian Hackett
Boris Zbarsky
Brian Grinstead
Mark Banner
Yoshi Cheng-Hao Huang
Zibi Braniecki
Sebastian Hengst
Ryan Hunt
Kris Maglione
Gurzau Raul
Ciure Andrei
Jan de Mooij
Sylvestre Ledru
Ehsan Akhgari
Cosmin Sabou
Andreea Pavel
Alex Gaynor
Perry Jiang
Jeff Gilbert
Jean-Yves Avenard
Nika Layzell