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
I changed DelegatedQueryInterface and CallMethod to be non-static
methods rather than taking an explicit |self| parameter.
There is already a method nsXPCWrappedJS::CallMethod() with the same
signature, but it is a shim, so I inlined it into the version in
XPCWrappedJSClass.cpp.
I also fixed up a few comments that mention nsXPCWrappedJSClass.
The new comments starting with "We now need to enter the realm" were
written by Boris, and are a little more explicit so they are easier to
understand.
I renamed DebugDump() to DebugDumpInterfaceInfo() to be more
informative.
Differential Revision: https://phabricator.services.mozilla.com/D26422
--HG--
extra : moz-landing-system : lando
I changed DelegatedQueryInterface and CallMethod to be non-static
methods rather than taking an explicit |self| parameter.
I did a tiny bit of cleanup in the nsIXPConnectJSObjectHolder case of
DelegatedQueryInterface().
There is already a method nsXPCWrappedJS::CallMethod() with the same
signature, but it is a shim, so I inlined it into the version in
XPCWrappedJSClass.cpp.
I also fixed up a few comments that mention nsXPCWrappedJSClass.
The new comments starting with "We now need to enter the realm" were
written by Boris, and are a little more explicit so they are easier to
understand.
I renamed DebugDump() to DebugDumpInterfaceInfo() to be more
informative.
Differential Revision: https://phabricator.services.mozilla.com/D26422
--HG--
extra : moz-landing-system : lando
