This was only ever useful before we had compartment-based security isolation.
Now it is just a pervasive nuisance.
Differential Revision: https://phabricator.services.mozilla.com/D10795
--HG--
extra : rebase_source : 9af37bbd959b2db3d7a6c5ac723a474c47676f79
These tests were timing out because `about:home` now runs in a different process.
Since these two tests aim to test something else (e.g. window leaks when
navigating between pages), we will redirect to a URL that loads in the same
process instead of `about:home` to avoid adding extra conditions for the
process flip.
See Bug 1336811 and Bug 1242643.
MozReview-Commit-ID: G0rhfA973R9
--HG--
extra : source : a28443371b944ee00b1267dd5b9a22da6d28353b
extra : intermediate-source : 7b7fa6ab2229e358666d0b0855adcfe6bd8199c4
extra : histedit_source : 6dae3cdd2834fc39ba547520cc6016ce4496cc08
These tests were timing out because `about:home` now runs in a different process.
Since these two tests aim to test something else (e.g. window leaks when
navigating between pages), we will redirect to a URL that loads in the same
process instead of `about:home` to avoid adding extra conditions for the
process flip.
See Bug 1336811 and Bug 1242643.
MozReview-Commit-ID: G0rhfA973R9
--HG--
extra : rebase_source : 158eb53174faa028edeebaf5970c123ba359a3e5
extra : intermediate-source : ebdca743668ce014c1cb9adfa00c1220256d357c
extra : source : a28443371b944ee00b1267dd5b9a22da6d28353b
These tests were timing out because `about:home` now runs in a different process.
Since these two tests aim to test something else (e.g. window leaks when
navigating between pages), we will redirect to a URL that loads in the same
process instead of `about:home` to avoid adding extra conditions for the
process flip.
See Bug 1336811 and Bug 1242643.
MozReview-Commit-ID: G0rhfA973R9
--HG--
extra : rebase_source : 614b8f5ac2a3ae9a1027c989d37aeba1026f886a
extra : source : a28443371b944ee00b1267dd5b9a22da6d28353b
I left GetMethodInfo, GetConstant as they are still useful as separate methods.
Differential Revision: https://phabricator.services.mozilla.com/D9638
--HG--
extra : moz-landing-system : lando
After the previous patches, we no longer rely on the component manager
to incidentally start up XPConnect when we load the JS loader service
or to hold the JS component loader alive, so the do_GetService() call
for the JS loader in XPCOMInit.cpp can be removed. After that is done,
the JS loader is no longer used as an XPCOM component, so all of the
boilerplate for that can be removed.
Depends on D8757
Differential Revision: https://phabricator.services.mozilla.com/D8758
--HG--
extra : moz-landing-system : lando
The JS component loader is an XPCOM component, so it is held alive by
the component manager. In order to be able to make it no longer be an
XPCOM component, we have to keep it alive some other way. I decided to
simply keep it alive as long as XPConnect itself is alive.
Depends on D9583
Differential Revision: https://phabricator.services.mozilla.com/D8757
--HG--
extra : moz-landing-system : lando
This changeset updates all the test that were wrongly using ok() and wanted to
use is() AND for which the assert is still passing without any modification
required.
Differential Revision: https://phabricator.services.mozilla.com/D8739
--HG--
extra : moz-landing-system : lando
Now that the XPCOM component loader infrastructure has stopped
pretending to support other file extensions, this intermediate
interface is no longer needed.
Depends on D8171
Differential Revision: https://phabricator.services.mozilla.com/D8172
--HG--
extra : moz-landing-system : lando
JS is the only file extension actually supported, and there are a few
layers of cruft that can be eliminated if we specialize it.
This eliminates one XPCOM registration of the JS component loader.
Depends on D8170
Differential Revision: https://phabricator.services.mozilla.com/D8171
--HG--
extra : moz-landing-system : lando
This interface is only used for a few testing functions. Just move
them to Cu.
Differential Revision: https://phabricator.services.mozilla.com/D8168
--HG--
extra : moz-landing-system : lando
SxS assemblies do not obey the usual DLL search order. It will make it possible
to load mozglue.dll from appdir even if the PreferSystem32Images mitigation is
enabled and System32 has a random mozglue.dll.
In FxAccountsComponents.manifest, the previous line registers the
component CID, but only for the main process. This means we hit an
error while parsing the manifest in the child process, because the CID
is not recognized. The fix is simply to not try to use the CID to
register the contract in the child process.
As for the rest of the changes, since bug 1438688, XPT information is
compiled into the Firefox binary, so the interfaces manifest entry is
no longer needed. This patch removes instances of this line from
manifest files. This makes some manifest files empty, so the patch
also removes the now-empty files.
Differential Revision: https://phabricator.services.mozilla.com/D8751
--HG--
extra : moz-landing-system : lando
This only requires changing the surrounding test boilerplate and using
SpecialPowers to access chrome-privileged functions.
Depends on D8132
Differential Revision: https://phabricator.services.mozilla.com/D8133
--HG--
extra : moz-landing-system : lando
This patch moves some Chrome mochitests into the plain mochitest
directory, in order to try to preserve the history. It also removes
them from the list of tests. The next patch will fix the tests and
start running them again.
Depends on D8131
Differential Revision: https://phabricator.services.mozilla.com/D8132
--HG--
rename : js/xpconnect/tests/chrome/test_getweakmapkeys.xul => js/xpconnect/tests/mochitest/test_getweakmapkeys.html
rename : js/xpconnect/tests/chrome/test_paris_weakmap_keys.xul => js/xpconnect/tests/mochitest/test_paris_weakmap_keys.html
rename : js/xpconnect/tests/chrome/test_weakmaps.xul => js/xpconnect/tests/mochitest/test_weakmaps.html
extra : moz-landing-system : lando
getter_AddRefs for nsCOMPtr does an AssertNoQueryNeeded check when its
temporary is destroyed. For the mReaderThread, this happens at a time when
control of the member variable has been handed over to the reader thread,
which causes a data race in the query needed check when the reader thread
shuts itself down and clears the member.
Switching to RefPtr solves this problem by removing the unnecessary check.
Differential Revision: https://phabricator.services.mozilla.com/D8135
--HG--
extra : rebase_source : 0532d152b6be57451e5729bf6b72e2056f3ed300
Gurzau Raul
Ehsan Akhgari
Kyle Machulis
Narcis Beleuzu
vinoth
Jonathan Kingston
Daniel Varga
Julian Descottes
Csoregi Natalia
Brindusan Cristian
Gabriele Svelto
Andrea Marchesini
Kris Maglione
Jay Lim
Ciure Andrei
Sebastian Hengst
Nika Layzell
Adrian Wielgosik
Andrew McCreight
Masatoshi Kimura
Dorel Luca
Sylvestre Ledru