These calls were changed from wrap() to rewrap() in bug 1291001.
Also, fix a minor typo in xpcprivate.h, because I didn't feel like
filing a separate bug for it.
Differential Revision: https://phabricator.services.mozilla.com/D31688
--HG--
extra : moz-landing-system : lando
Amend several test files for triggering eval() assertion through simpletest.js
Differential Revision: https://phabricator.services.mozilla.com/D30474
--HG--
extra : moz-landing-system : lando
We can run /debug mochitests against geckoview for the cost of another dozen
or so test annotations. Both /opt and /debug mochitests are nearly worthy of
tier 1, but still waiting for bug 1534732.
Differential Revision: https://phabricator.services.mozilla.com/D30931
--HG--
extra : moz-landing-system : lando
The semantics are that you get an empty array if the argument is not supplied,
and if [optional_argc] is used it's set accordingly so you can tell whether you
were passed explicit [] or not passed anything.
Differential Revision: https://phabricator.services.mozilla.com/D30850
--HG--
extra : moz-landing-system : lando
Amend several test files for triggering eval() assertion through simpletest.js
Differential Revision: https://phabricator.services.mozilla.com/D30474
--HG--
extra : moz-landing-system : lando
This patch fixes a race condition where we could request that a content page's
JS be cancelled during navigation in `HangMonitorChild::InterruptCallback`,
but the new page has already started loading by the time the JS is cancelled in
`XPCJSContext::InterruptCallback`, thus cancelling the JS of the new page. To
fix this, we now handle everything in `HangMonitorChild::InterruptCallback`,
making sure to only do anything for *content* scripts (to avoid inadvertently
cancelling the browser's JS).
Differential Revision: https://phabricator.services.mozilla.com/D30272
--HG--
extra : moz-landing-system : lando
These tests need to be disabled to get a green run on the Android x86_64
test platform. The failures in toolkit/components/extensions are
concerning and definitely require follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D29843
--HG--
extra : moz-landing-system : lando
Marking GetGlobalJSObject and GetGlobalJSObjectPreserveColor final and inline
on inner/outer windows allows compilers to de-virtualize and inline them, which
makes them just as fast as calling FastGetGlobalJSObject is now (in the case of
GetGlobalJSObjectPreserveColor; GetGlobalJSObject has to do the gray-unmarking,
which is a bit more work).
In WindowDestroyedEvent::Run we want to switch to GetGlobalJSObject(), because
we want to root the object and hence should unmark gray.
In nsGlobalWindowInner::RunTimeoutHandler we likewise want to unmark gray. The
AutoEntryScript constructor likely did that already, but it's not that
expensive when it doesn't need to do any work.
Differential Revision: https://phabricator.services.mozilla.com/D29711
--HG--
extra : moz-landing-system : lando
Consumers that just care about this boolean state should use this instead of
getting the JSObject* directly.
Differential Revision: https://phabricator.services.mozilla.com/D29705
--HG--
extra : moz-landing-system : lando
This can be used in things like assertions or some other rare circumstances
where not exposing the object to active JS is OK.
Differential Revision: https://phabricator.services.mozilla.com/D29704
--HG--
extra : moz-landing-system : lando
This patch passes a message through the HangMonitor channel when navigating
through history to cancel content JS that could hang the chrome JS in the
content process responsible for history navigation. If the content JS is
actually canceled, this also disables the BF cache for the current page, since
it could end up in an inconsistent state due to the JS cancellation.
Differential Revision: https://phabricator.services.mozilla.com/D23089
--HG--
extra : moz-landing-system : lando
There are currently some odd circumstances where we deadlock waiting for the
background save thread to finish while it is blocked on sync dispatch to the
main thread during shutdown.
There were existing workarounds to prevent this, which tried to synchronously
complete the main thread work required by the background thread at the start
of shutdown, and some fallback anti-deadlock assertions to catch any remaining
corner cases, but apparently Fennec has corner cases of its own that we didn't
anticipate.
This patch takes the more straightforward route of using an async shutdown
blocker, which allows the async shutdown service to safely spin the event loop
until the save completes, rather than an independent monitor loop, which does
not.
It also fixes a potential data race where the save thread could clear its
mSaveThread member before NS_NewNamedThread returned, running afoul of
nsCOMPtr sanity checks.
Differential Revision: https://phabricator.services.mozilla.com/D28127
--HG--
extra : rebase_source : 4aed24f4a255063d87dff2609e9913418d5c16fa
This makes it more obvious that it is an XPIDL interface.
I also changed a RefPtr<> to an nsCOMPtr<>.
Differential Revision: https://phabricator.services.mozilla.com/D28235
--HG--
extra : moz-landing-system : lando
This patch passes a message through the HangMonitor channel when navigating
through history to cancel content JS that could hang the chrome JS in the
content process responsible for history navigation. If the content JS is
actually canceled, this also disables the BF cache for the current page, since
it could end up in an inconsistent state due to the JS cancellation.
Differential Revision: https://phabricator.services.mozilla.com/D23089
--HG--
extra : moz-landing-system : lando
On startup we record the size and modified time of the profile lists. If
changed we refuse to flush any new changes to disk. Also adds a getter to check
if they've changed so the UI can do something sensible.
All attempts to flush are now checked for success. In some cases in early
startup the failure mode isn't great, we just quit startup. The assumption
though is that it's extremely unlikely that the files will have changed on disk
in the time between when they are read and when profile selection occurs, likely
less than a second later.
The profile reset flow is changed to only delete the old profile and flush once
all the migration has completed, so if something fails the user gets back to
their old profile.
In testing I ended up having to fix bug 1522584 so background file deletions on
a background thread are safer.
I haven't implemented any UI tests right now since making modifications to the
profiles means modifying the actual user's profiles which I'm not keen to do.
See bug 1539868.
Differential Revision: https://phabricator.services.mozilla.com/D25278
--HG--
extra : rebase_source : b9fb01c5f2faaf7d534800b700bb02b8c88af023
extra : source : ad5ac4d5c8f7240809a205be2960924813f1e705
On startup we record the size and modified time of the profile lists. If
changed we refuse to flush any new changes to disk. Also adds a getter to check
if they've changed so the UI can do something sensible.
All attempts to flush are now checked for success. In some cases in early
startup the failure mode isn't great, we just quit startup. The assumption
though is that it's extremely unlikely that the files will have changed on disk
in the time between when they are read and when profile selection occurs, likely
less than a second later.
The profile reset flow is changed to only delete the old profile and flush once
all the migration has completed, so if something fails the user gets back to
their old profile.
In testing I ended up having to fix bug 1522584 so background file deletions on
a background thread are safer.
I haven't implemented any UI tests right now since making modifications to the
profiles means modifying the actual user's profiles which I'm not keen to do.
See bug 1539868.
Differential Revision: https://phabricator.services.mozilla.com/D25278
--HG--
extra : moz-landing-system : lando
On startup we record the size and modified time of the profile lists. If
changed we refuse to flush any new changes to disk. Also adds a getter to check
if they've changed so the UI can do something sensible.
All attempts to flush are now checked for success. In some cases in early
startup the failure mode isn't great, we just quit startup. The assumption
though is that it's extremely unlikely that the files will have changed on disk
in the time between when they are read and when profile selection occurs, likely
less than a second later.
The profile reset flow is changed to only delete the old profile and flush once
all the migration has completed, so if something fails the user gets back to
their old profile.
In testing I ended up having to fix bug 1522584 so background file deletions on
a background thread are safer.
I haven't implemented any UI tests right now since making modifications to the
profiles means modifying the actual user's profiles which I'm not keen to do.
See bug 1539868.
Differential Revision: https://phabricator.services.mozilla.com/D25278
--HG--
extra : moz-landing-system : lando
This excludes dom/, otherwise 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/D27456
--HG--
extra : moz-landing-system : lando
Currently, JSAPI malloc calls can only allocate in MallocArena. Now there
are calls for when the user intends to allocate a buffer that will be
"stolen" by one of the NewString calls.
Differential Revision: https://phabricator.services.mozilla.com/D25709
--HG--
extra : moz-landing-system : lando
