A couple of changes to ensure that the mochitest harness doesn't try to
start executing changes before the mochitest extension is loaded:
1. Fix the marionette driver to wait for an installed extension to
be started before returning from Addon:install
2. Wait for extension API onStartup() handlers to finish before
considering a webextension started.
MozReview-Commit-ID: 8YEdNn6s5qh
--HG--
extra : rebase_source : 67e9abadcda82d55ac73c33367ec65cdbf7b823d
Support for the _xpcom_categories property was removed in Bug 568691,
but we left a bunch of consumers behind, and it's been cargo-culted a bit more.
We should remove the remaining remnants.
Differential Revision: https://phabricator.services.mozilla.com/D2429
--HG--
extra : moz-landing-system : lando
This new id is added in the PerformanceInfo data and helps consumers distinguish
counters.
MozReview-Commit-ID: 7kEmqJcVggM
--HG--
extra : rebase_source : 40cca4c937f846db93ec1315036ad1bac04bc762
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
BackgroundHangMonitor is a special snowflake, and uses PR_CreateThread
directly, for some reason.
MozReview-Commit-ID: 2Qg28EqDwM7
--HG--
extra : rebase_source : b59ac1b42ae283a1bcabe4e24ac3df92a11de6e2
extra : intermediate-source : 771288dbf8529d45786b42a21dc66b180bb674ca
extra : source : b2a99f50e642cc3dc41ab540e7639d2c39bbe75b
Adds a performance counter in ParentAPIManager to track the
number and duration of API calls by webextensions.
MozReview-Commit-ID: PTpaSCkE6A
--HG--
extra : rebase_source : 21c6c7f2e38c8808771fe4fea90d2750196202bd
Tested the functionality of 'CombinedStacks'. Added coverage for 'AddStack' and 'RemoveStack' methods.
MozReview-Commit-ID: CxBZHHZMN3z
--HG--
extra : rebase_source : 72ded4aebcbcd7b6a9e1b510326f64670b7b0f55
The test_partialUpdateV4() test case doesn't wait for the update task
to be finished. It checks the status in the HTTP server side and then calls
run_next_test(). However, when XPCShell test is done, it will trigger
the shutdown process and hence interrupt the ongoing update task.
This cause the xpcshell test receives an error since the update is
interrupted and returns an error like NS_ERROR_UC_UPDATE_SHUTDOWNING.
This patch also fixes a javascript error that we didn't stop the httpd
server when cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D2360
--HG--
extra : moz-landing-system : lando
BackgroundHangMonitor is a special snowflake, and uses PR_CreateThread
directly, for some reason.
MozReview-Commit-ID: 2Qg28EqDwM7
--HG--
extra : source : b2a99f50e642cc3dc41ab540e7639d2c39bbe75b
extra : histedit_source : 603bd726eafdb53aaafd98337b41da1259464cc7
BackgroundHangMonitor is a special snowflake, and uses PR_CreateThread
directly, for some reason.
MozReview-Commit-ID: 2Qg28EqDwM7
--HG--
extra : rebase_source : dd924decb23d1d8107eb317be5d2ac1b92328408
This is an optimization that reduces the memory usage of the registeredUrls list (as it will use shared data among all processes), and makes the Register/Unregister messages unecessary since the changes in sharedData are automatically propagated to all running processes.
The flush() is unfortunately needed to force the propagation in this case, otherwise it would propagate on the next idle tick, and that is not enough to make sure that the RemotePageManager works for the first about:newtab created when starting Firefox
MozReview-Commit-ID: JG3na0XXWA2
--HG--
extra : rebase_source : 1db486512363fc853293ea0ef35f0be8aac882e2
This moves the code responsible for listening for document creation out of RemotePageManagerChild.jsm into process-content.js, so that the rest of the code in RemotePageManagerChild.jsm is not loaded unecessarily.
Note: The Register/Unregister messages are included in this patch for correctness, but they will be removed by optimizations from the next patch
MozReview-Commit-ID: LxV481rfanV
--HG--
extra : rebase_source : 55af52097b4d98052a98327a7d4c6f864eadc37e
The RemotePageManager.jsm contains code both for the parent and child processes, which makes some code to be unecessarily loaded twice. This patch splits it up in various parts:
RemotePageManagerParent.jsm - code meant for the parent process
RemotePageManagerChild.jsm - code meant for child processes
MessagePort.jsm - code used by both the parent and child code paths (the base MessagePort and MessageListener)
MozReview-Commit-ID: 1fUoQ5Y29xM
--HG--
rename : toolkit/modules/RemotePageManager.jsm => toolkit/components/remotepagemanager/MessagePort.jsm
rename : toolkit/modules/RemotePageManager.jsm => toolkit/components/remotepagemanager/RemotePageManagerChild.jsm
rename : toolkit/modules/RemotePageManager.jsm => toolkit/components/remotepagemanager/RemotePageManagerParent.jsm
extra : rebase_source : 828b57b305274abbf55710bc58325a087e5b6cc4
