Otherwise, LTO will eliminate it because the compiler can't see the
calls to PrepareAndDispatch from the relevant assembly file.
Differential Revision: https://phabricator.services.mozilla.com/D26244
--HG--
extra : moz-landing-system : lando
ARM's xptcstubs use a slightly different setup for PrepareAndDispatch
than...well, all of our other stubs. This difference appears to be
causing problems with LTO builds. Change the setup to be more like our
other stubs, which additionally gets rid of some of the `asm` nonsense.
Differential Revision: https://phabricator.services.mozilla.com/D26243
--HG--
extra : moz-landing-system : lando
XPCConvert::IsMethodReflectable() is derived entirely from
nsXPTMethodInfo, so we can compute it at build time and include it in
nsXPTMethodInfo. It is the only use of mNotXPCOM and mHidden, so we
can get rid of those fields at the same time.
This paves the way for getting rid of XPCWrappedJSClass::mDescriptors
in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D26070
--HG--
extra : moz-landing-system : lando
PR_SetCurrentThreadName() is broken on Android (Bug 1541216).
In order to work around this issue, NS_SetCurrentThreadName() will
call prctl(PR_SET_NAME, name) until the underlying nspr can be
fixed.
Differential Revision: https://phabricator.services.mozilla.com/D25891
--HG--
extra : moz-landing-system : lando
I am 90% sure that this is wrong but this is the only way I can get it to
compile and work. Unlike other examples of supporting MOZ_DBG it only declares
an operator for `nsIURI* not` `const nsIURI`. I had to drop the const because
then I couldn't call GetSpec as it isn't marked const. I had to switch to a
pointer since otherwise it would complain about virtual methods.
Still in practice this works, I think it is rare that we hold an nsIURI in
anything other than a pointer and same for the constness.
Differential Revision: https://phabricator.services.mozilla.com/D25669
--HG--
extra : rebase_source : 9760674375563ec312568caf4a5ad46facfb6f68
In addition to knowing whether we're running x86-on-x86-64, we'd also
like to know about the x86-on-arm64 case. The current code doesn't
provide enough information to determine that, so we need to query a
little bit harder.
The img decode API allows a web author to request that an image be
decoded at its intrinsic size and be notified when it has been
completed. This is useful to ensure an image is ready to display before
adding it to the DOM tree -- this will help reduce flickering.
Differential Revision: https://phabricator.services.mozilla.com/D11362
1. Adding a new attribute chromeContext in ConsoleEvent
2. Adding a new boolean attribute isFromChromeContext in nsIConsoleMessage
3. Sending IsFromChromeContext to the parent process
Differential Revision: https://phabricator.services.mozilla.com/D23330
--HG--
extra : moz-landing-system : lando
Testing has determined that doing this has no detrimental size benefit,
and a small positive performance impact.
Differential Revision: https://phabricator.services.mozilla.com/D25848
--HG--
extra : moz-landing-system : lando
Mechanical change from Matcher::match(...) to Matcher::operator()(...).
This will now permit the use of generic lambdas, and facilitate the
implementation of multi-lambda match.
Differential Revision: https://phabricator.services.mozilla.com/D24889
--HG--
extra : moz-landing-system : lando
This way we don't have to go through a bunch of printf nonsense, and we
ought to be able to arrive at optimized routines that take advantage of
constant radices, etc.
Differential Revision: https://phabricator.services.mozilla.com/D25141
--HG--
extra : moz-landing-system : lando
Outside code shouldn't have to care how many levels of priority
PrioritizedEventQueue manages.
Differential Revision: https://phabricator.services.mozilla.com/D25226
--HG--
extra : moz-landing-system : lando
Originally we stored the new information about installation defaults in
installs.ini since older versions of Firefox would throw away any new data in
profiles.ini any time they made changes to the profiles. That does however mean
we have to load two files on startup.
This changes things so that we save all the data in profiles.ini as well as a
version tag and still save the install data into installs.ini. An older version
will throw away the install data and version tag from profiles.ini but leave
installs.ini alone. On startup if the version tag is gone from profiles.ini then
we reload the install data from installs.ini and put it back into profiles.ini.
At some point in the future where we don't care about supporting older versions
of Firefox we can just drop installs.ini entirely.
A lot of the changes here involve moving to loading profiles.ini into an
in-memory ini, keeping it up to date and flushing it to disk. This means that we
no longer throw away any information in the ini file that this version does not
understand allowing the possibility of adding new data to this file in the
future.
Differential Revision: https://phabricator.services.mozilla.com/D22576
--HG--
extra : rebase_source : d00edf1ceb200a73a60bb1a90afabcdf95b01acf
extra : intermediate-source : e1c9790cd3bee060da99ffe37026721e36bc46c3
extra : source : d4feb17faf013134f5eac8b5e19b714c56410973
Cache the result of nsMacUtilsImpl::GetAppPath() to avoid doing I/O on repeated calls.
Differential Revision: https://phabricator.services.mozilla.com/D22410
--HG--
extra : moz-landing-system : lando
Originally we stored the new information about installation defaults in
installs.ini since older versions of Firefox would throw away any new data in
profiles.ini any time they made changes to the profiles. That does however mean
we have to load two files on startup.
This changes things so that we save all the data in profiles.ini as well as a
version tag and still save the install data into installs.ini. An older version
will throw away the install data and version tag from profiles.ini but leave
installs.ini alone. On startup if the version tag is gone from profiles.ini then
we reload the install data from installs.ini and put it back into profiles.ini.
At some point in the future where we don't care about supporting older versions
of Firefox we can just drop installs.ini entirely.
A lot of the changes here involve moving to loading profiles.ini into an
in-memory ini, keeping it up to date and flushing it to disk. This means that we
no longer throw away any information in the ini file that this version does not
understand allowing the possibility of adding new data to this file in the
future.
Differential Revision: https://phabricator.services.mozilla.com/D22576
--HG--
extra : moz-landing-system : lando
Originally we stored the new information about installation defaults in
installs.ini since older versions of Firefox would throw away any new data in
profiles.ini any time they made changes to the profiles. That does however mean
we have to load two files on startup.
This changes things so that we save all the data in profiles.ini as well as a
version tag and still save the install data into installs.ini. An older version
will throw away the install data and version tag from profiles.ini but leave
installs.ini alone. On startup if the version tag is gone from profiles.ini then
we reload the install data from installs.ini and put it back into profiles.ini.
At some point in the future where we don't care about supporting older versions
of Firefox we can just drop installs.ini entirely.
A lot of the changes here involve moving to loading profiles.ini into an
in-memory ini, keeping it up to date and flushing it to disk. This means that we
no longer throw away any information in the ini file that this version does not
understand allowing the possibility of adding new data to this file in the
future.
Differential Revision: https://phabricator.services.mozilla.com/D22576
--HG--
extra : moz-landing-system : lando
1. Adding a new attribute chromeContext in ConsoleEvent
2. Adding a new boolean attribute isFromChromeContext in nsIConsoleMessage
3. Sending IsFromChromeContext to the parent process
Differential Revision: https://phabricator.services.mozilla.com/D23330
--HG--
extra : moz-landing-system : lando
Originally we stored the new information about installation defaults in
installs.ini since older versions of Firefox would throw away any new data in
profiles.ini any time they made changes to the profiles. That does however mean
we have to load two files on startup.
This changes things so that we save all the data in profiles.ini as well as a
version tag and still save the install data into installs.ini. An older version
will throw away the install data and version tag from profiles.ini but leave
installs.ini alone. On startup if the version tag is gone from profiles.ini then
we reload the install data from installs.ini and put it back into profiles.ini.
At some point in the future where we don't care about supporting older versions
of Firefox we can just drop installs.ini entirely.
A lot of the changes here involve moving to loading profiles.ini into an
in-memory ini, keeping it up to date and flushing it to disk. This means that we
no longer throw away any information in the ini file that this version does not
understand allowing the possibility of adding new data to this file in the
future.
Differential Revision: https://phabricator.services.mozilla.com/D22576
--HG--
extra : moz-landing-system : lando
This is done by incorporating the ensure_param macro into the implementation of the xpcom_method macro
Differential Revision: https://phabricator.services.mozilla.com/D23568
--HG--
extra : moz-landing-system : lando
This commit adds `ThreadPtr{Handle, Holder}` to wrap an `XpCom` object
with thread-safe refcounting. These are analagous to
`nsMainThreadPtr{Handle, Holder}`, but can hold references to
objects from any thread, not just the main thread.
`ThreadPtrHolder` is similar to `ThreadBoundRefPtr`. However, it's
not possible to clone a `ThreadBoundRefPtr`, so it can't be shared
among tasks. This is fine for objects that are only used once, like
callbacks. However, `ThreadBoundRefPtr` doesn't work well for loggers
or event emitters, which might need to be called multiple times on
the owning thread.
Unlike a `ThreadBoundRefPtr`, it's allowed and expected to
clone and drop a `ThreadPtrHolder` on other threads. Internally,
the holder keeps an atomic refcount, and releases the wrapped object
on the owning thread once the count reaches zero.
This commit also changes `TaskRunnable` to support dispatching from
threads other than the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D20074
--HG--
extra : moz-landing-system : lando
This commit wraps just enough of the mozStorage API to support the
bookmarks mirror. It's not complete: for example, there's no way
to open, clone, or close a connection, because the mirror handles
that from JS. The wrapper also omits shutdown blocking and retrying on
`SQLITE_BUSY`.
This commit also changes the behavior of sync and async mozStorage
connections. Async (`mozIStorageAsyncConnection`) methods may be called
from any thread on any connection. Sync (`mozIStorageConnection`)
methods may be called from any thread on a sync connection, and from
background threads on an async connection. All connections now QI
to `mozIStorageConnection`, but attempting to call a sync method on
an async connection from the main thread throws.
Finally, this commit exposes an `OpenedConnection::unsafeRawConnection`
getter in Sqlite.jsm, for JS code to access the underlying connection.
Differential Revision: https://phabricator.services.mozilla.com/D20073
--HG--
extra : moz-landing-system : lando
Before the Array<T> type, the calltype argument could be in, out, or inout,
however with Array<T> the element type was added.
When I added Array<T>, I changed the checks in files which check calltype !=
'in' to instead check 'out' in calltype, such that element would act more like
in in most cases (not adding the outparam *).
However, I never made that change for rust code, as it didn't support Array<T>
at the time. When I turned on Array<T> support for rust code, I forgot to go
through and change the conditions, which lead to this bug.
Differential Revision: https://phabricator.services.mozilla.com/D24283
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
The definitions can't be entirely removed yet because NSS still needs them.
Differential Revision: https://phabricator.services.mozilla.com/D23454
--HG--
extra : moz-landing-system : lando
The old code for member method calls did the following:
1) Find the member method calls.
2) Look at their "this" expression.
3) If the "this" is an operator call, check for any of the arguments of the
operator call being invalid.
4) Otherwise (if not an operator call) check for the "this" value being
invalid.
This wasn't right, because the "is invalid" check checks the type and only
considers refcounted things. So if the code looked something like
"foo[i]->call_method()", we would look at the types of "foo" and "i" and
determine that none of those are refcounted types so there is nothing invalid
here (since "foo" is some sort of array type and "i" is an integer). The new
setup just checks whether the "this" value is invalid, which does the type
check on the "this" value itself; in the "foo[i]->call_method()" case on
"foo[i]". We then adjust the exclusions in InvalidArg to consider operator->
on known-live things valid, to allow the thing that we were really trying to
accomplish with the "check for an operator call" bits:
"stackRefPtr->some_method()".
The test coverage being added for the made-up TArray type is meant to catch
things like the geolocation issue that was being hidden by the buggy behavior.
I'm not using nsTArray itself because some header included by nsTArray.h
tries to define operator new/delete bits inline and that triggers warnings that
then cause a clang-plugin test failure, because they're unexpected.
Differential Revision: https://phabricator.services.mozilla.com/D24117
--HG--
extra : moz-landing-system : lando
"this" is guaranteed to stay alive as long as other MOZ_CAN_RUN_SCRIPT
conditions hold, and its const members can't change value and drop
their refs.
Differential Revision: https://phabricator.services.mozilla.com/D23997
--HG--
extra : moz-landing-system : lando
The old code for member method calls did the following:
1) Find the member method calls.
2) Look at their "this" expression.
3) If the "this" is an operator call, check for any of the arguments of the
operator call being invalid.
4) Otherwise (if not an operator call) check for the "this" value being
invalid.
This wasn't right, because the "is invalid" check checks the type and only
considers refcounted things. So if the code looked something like
"foo[i]->call_method()", we would look at the types of "foo" and "i" and
determine that none of those are refcounted types so there is nothing invalid
here (since "foo" is some sort of array type and "i" is an integer). The new
setup just checks whether the "this" value is invalid, which does the type
check on the "this" value itself; in the "foo[i]->call_method()" case on
"foo[i]". We then adjust the exclusions in InvalidArg to consider operator->
on known-live things valid, to allow the thing that we were really trying to
accomplish with the "check for an operator call" bits:
"stackRefPtr->some_method()".
The test coverage being added for the made-up TArray type is meant to catch
things like the geolocation issue that was being hidden by the buggy behavior.
I'm not using nsTArray itself because some header included by nsTArray.h
tries to define operator new/delete bits inline and that triggers warnings that
then cause a clang-plugin test failure, because they're unexpected.
Differential Revision: https://phabricator.services.mozilla.com/D24117
--HG--
extra : moz-landing-system : lando
"this" is guaranteed to stay alive as long as other MOZ_CAN_RUN_SCRIPT
conditions hold, and its const members can't change value and drop
their refs.
Differential Revision: https://phabricator.services.mozilla.com/D23997
--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
We should catch these issues ASAP. This NS_ASSERTION also bit me in the past.
Differential Revision: https://phabricator.services.mozilla.com/D24115
--HG--
extra : moz-landing-system : lando
After analyzing crash ping data we've established that the current low-memory
detection threshold is too low, there are still a fair number of crashes
happening above it. A 50% increase to 384 MiB should be just about right in
the light of recent telemetry data.
Differential Revision: https://phabricator.services.mozilla.com/D23826
--HG--
extra : moz-landing-system : lando
NS_InitXPCOM() is currently not called in Gecko. It has been a one-line wrapper around NS_InitXPCOM2() since the year 2000 (bug 46320), presumably to maintain ABI compatibility for third-party users of XPCOM. We no longer need to worry about XPCOM ABI compatibility.
https://searchfox.org/mozilla-central/commit/cddb62593d786e0ff12b25037c74b01cb1a802e5
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
xpcom/build/XPCOMInit.cpp:187:1 [-Wmissing-prototypes] no previous prototype for function 'NS_InitXPCOM'
Differential Revision: https://phabricator.services.mozilla.com/D23266
--HG--
extra : rebase_source : 0ad5580e2978a8d5141bd6a9623c5af7359c78ca
extra : source : a9e4205868dbb847c01980051a56e99ad24a8ac1
The NonASCII16 test function was removed in bug 1402247 but the NonASCII16_helper() function was not:
https://hg.mozilla.org/mozilla-central/rev/4ef0f163fdeb
xpcom/tests/gtest/TestUTF.cpp:119:6 [-Wmissing-prototypes] no previous prototype for function 'NonASCII16_helper'
Differential Revision: https://phabricator.services.mozilla.com/D23267
--HG--
extra : rebase_source : c53118479acc6ea866dafb04617bfb2706dddb2b
extra : source : de3a70ccef6c09d0d317c7b4b5c1f8a2f93d78c7
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called). The .cpp files defining these functions did not include the headers with the corresponding function prototypes used by other compilation units. Including a header file in its corresponding .cpp file can help catch mismatched declarations and definitions.
xpcom/components/nsCategoryManager.cpp:637:6 [-Wmissing-prototypes] no previous prototype for function 'NS_CreateServicesFromCategory'
xpcom/io/nsPipe3.cpp:1824:10 [-Wmissing-prototypes] no previous prototype for function 'nsPipeConstructor'
xpcom/io/nsStringStream.cpp:475:10 [-Wmissing-prototypes] no previous prototype for function 'nsStringInputStreamConstructor'
xpcom/threads/ThreadDelay.cpp:18:6 [-Wmissing-prototypes] no previous prototype for function 'DelayForChaosMode'
Differential Revision: https://phabricator.services.mozilla.com/D23265
--HG--
extra : rebase_source : a2085a090394a5d3f5c319258b782a5d9f217751
extra : source : 18c3e569ff15987eb200c62eaa9f4943ff08cb25
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
xpcom/base/Logging.cpp:85:13 [-Wmissing-prototypes] no previous prototype for function 'ToLogStr'
xpcom/base/Logging.cpp:132:13 [-Wmissing-prototypes] no previous prototype for function 'ExpandPIDMarker'
xpcom/base/LogModulePrefWatcher.cpp:37:6 [-Wmissing-prototypes] no previous prototype for function 'ResetExistingPrefs'
xpcom/base/LogModulePrefWatcher.cpp:109:6 [-Wmissing-prototypes] no previous prototype for function 'LoadExistingPrefs'
xpcom/base/nsCycleCollector.cpp:212:6 [-Wmissing-prototypes] no previous prototype for function 'SuspectUsingNurseryPurpleBuffer'
xpcom/components/nsComponentManager.cpp:421:31 [-Wmissing-prototypes] no previous prototype for function 'begin'
xpcom/components/nsComponentManager.cpp:427:31 [-Wmissing-prototypes] no previous prototype for function 'end'
xpcom/ds/Dafsa.cpp:23:6 [-Wmissing-prototypes] no previous prototype for function 'GetNextOffset'
xpcom/ds/Dafsa.cpp:55:6 [-Wmissing-prototypes] no previous prototype for function 'IsEOL'
xpcom/ds/Dafsa.cpp:62:6 [-Wmissing-prototypes] no previous prototype for function 'IsMatch'
xpcom/ds/Dafsa.cpp:70:6 [-Wmissing-prototypes] no previous prototype for function 'IsEndCharMatch'
xpcom/ds/Dafsa.cpp:78:6 [-Wmissing-prototypes] no previous prototype for function 'GetReturnValue'
xpcom/ds/Dafsa.cpp:91:5 [-Wmissing-prototypes] no previous prototype for function 'LookupString'
xpcom/io/CocoaFileUtils.mm:195:13 [-Wmissing-prototypes] no previous prototype for function 'GetQuarantinePropKey'
xpcom/io/CocoaFileUtils.mm:203:24 [-Wmissing-prototypes] no previous prototype for function 'CreateQuarantineDictionary'
xpcom/rust/gtest/bench-collections/Bench.cpp:65:11 [-Wmissing-prototypes] no previous prototype for function 'MyRand'
xpcom/rust/gtest/bench-collections/Bench.cpp:85:6 [-Wmissing-prototypes] no previous prototype for function 'Bench_Cpp_unordered_set'
xpcom/rust/gtest/bench-collections/Bench.cpp:125:6 [-Wmissing-prototypes] no previous prototype for function 'Bench_Cpp_PLDHashTable'
xpcom/rust/gtest/bench-collections/Bench.cpp:166:6 [-Wmissing-prototypes] no previous prototype for function 'Bench_Cpp_MozHashSet'
xpcom/tests/gtest/TestAtoms.cpp:114:6 [-Wmissing-prototypes] no previous prototype for function 'isStaticAtom'
xpcom/tests/gtest/TestCallTemplates.cpp:72:6 [-Wmissing-prototypes] no previous prototype for function 'JustTestingCompilation'
xpcom/tests/gtest/TestCOMPtr.cpp:87:10 [-Wmissing-prototypes] no previous prototype for function 'CreateIFoo'
xpcom/tests/gtest/TestCOMPtr.cpp:98:6 [-Wmissing-prototypes] no previous prototype for function 'set_a_IFoo'
xpcom/tests/gtest/TestCOMPtr.cpp:105:16 [-Wmissing-prototypes] no previous prototype for function 'return_a_IFoo'
xpcom/tests/gtest/TestCOMPtr.cpp:164:10 [-Wmissing-prototypes] no previous prototype for function 'CreateIBar'
xpcom/tests/gtest/TestCOMPtr.cpp:175:6 [-Wmissing-prototypes] no previous prototype for function 'AnIFooPtrPtrContext'
xpcom/tests/gtest/TestCOMPtr.cpp:177:6 [-Wmissing-prototypes] no previous prototype for function 'AVoidPtrPtrContext'
xpcom/tests/gtest/TestCOMPtr.cpp:179:6 [-Wmissing-prototypes] no previous prototype for function 'AnISupportsPtrPtrContext'
xpcom/tests/gtest/TestCOMPtr.cpp:263:6 [-Wmissing-prototypes] no previous prototype for function 'Comparison'
xpcom/tests/gtest/TestCOMPtr.cpp:298:6 [-Wmissing-prototypes] no previous prototype for function 'DontAddRef'
xpcom/tests/gtest/TestCRT.cpp:17:5 [-Wmissing-prototypes] no previous prototype for function 'sign'
xpcom/tests/gtest/TestDeadlockDetector.cpp:62:6 [-Wmissing-prototypes] no previous prototype for function 'DisableCrashReporter'
xpcom/tests/gtest/TestDeadlockDetector.cpp:74:5 [-Wmissing-prototypes] no previous prototype for function 'Sanity_Child'
xpcom/tests/gtest/TestDeadlockDetector.cpp:95:5 [-Wmissing-prototypes] no previous prototype for function 'Sanity2_Child'
xpcom/tests/gtest/TestDeadlockDetector.cpp:159:5 [-Wmissing-prototypes] no previous prototype for function 'Sanity4_Child'
xpcom/tests/gtest/TestDeadlockDetector.cpp:182:5 [-Wmissing-prototypes] no previous prototype for function 'Sanity5_Child'
xpcom/tests/gtest/TestDeadlockDetector.cpp:303:5 [-Wmissing-prototypes] no previous prototype for function 'ContentionNoDeadlock_Child'
xpcom/tests/gtest/TestHashtables.cpp:88:6 [-Wmissing-prototypes] no previous prototype for function 'testTHashtable'
xpcom/tests/gtest/TestHashtables.cpp:205:10 [-Wmissing-prototypes] no previous prototype for function 'CreateIFoo'
xpcom/tests/gtest/TestMoveString.cpp:25:6 [-Wmissing-prototypes] no previous prototype for function 'SetAsOwned'
xpcom/tests/gtest/TestMoveString.cpp:34:6 [-Wmissing-prototypes] no previous prototype for function 'ExpectTruncated'
xpcom/tests/gtest/TestMoveString.cpp:40:6 [-Wmissing-prototypes] no previous prototype for function 'ExpectNew'
xpcom/tests/gtest/TestMruCache.cpp:52:11 [-Wmissing-prototypes] no previous prototype for function 'MakeStringKey'
xpcom/tests/gtest/TestMultiplexInputStream.cpp:106:34 [-Wmissing-prototypes] no previous prototype for function 'CreateStreamHelper'
xpcom/tests/gtest/TestNonBlockingAsyncInputStream.cpp:62:10 [-Wmissing-prototypes] no previous prototype for function 'ReadSegmentsFunction'
xpcom/tests/gtest/TestNsDeque.cpp:240:6 [-Wmissing-prototypes] no previous prototype for function 'CheckIfQueueEmpty'
xpcom/tests/gtest/TestNsRefPtr.cpp:105:10 [-Wmissing-prototypes] no previous prototype for function 'CreateFoo'
xpcom/tests/gtest/TestNsRefPtr.cpp:116:6 [-Wmissing-prototypes] no previous prototype for function 'set_a_Foo'
xpcom/tests/gtest/TestNsRefPtr.cpp:123:13 [-Wmissing-prototypes] no previous prototype for function 'return_a_Foo'
xpcom/tests/gtest/TestNsRefPtr.cpp:391:6 [-Wmissing-prototypes] no previous prototype for function 'AnFooPtrPtrContext'
xpcom/tests/gtest/TestNsRefPtr.cpp:392:6 [-Wmissing-prototypes] no previous prototype for function 'AVoidPtrPtrContext'
xpcom/tests/gtest/TestPLDHash.cpp:33:6 [-Wmissing-prototypes] no previous prototype for function 'TestCrashyOperation'
xpcom/tests/gtest/TestPipes.cpp:98:10 [-Wmissing-prototypes] no previous prototype for function 'TestPipe'
xpcom/tests/gtest/TestPipes.cpp:212:10 [-Wmissing-prototypes] no previous prototype for function 'TestShortWrites'
xpcom/tests/gtest/TestPipes.cpp:354:6 [-Wmissing-prototypes] no previous prototype for function 'RunTests'
xpcom/tests/gtest/TestPLDHash.cpp:90:6 [-Wmissing-prototypes] no previous prototype for function 'InitCapacityOk_InitialLengthTooBig'
xpcom/tests/gtest/TestPLDHash.cpp:95:6 [-Wmissing-prototypes] no previous prototype for function 'InitCapacityOk_InitialEntryStoreTooBig'
xpcom/tests/gtest/TestPLDHash.cpp:102:6 [-Wmissing-prototypes] no previous prototype for function 'InitCapacityOk_EntrySizeTooBig'
xpcom/tests/gtest/TestSlicedInputStream.cpp:111:20 [-Wmissing-prototypes] no previous prototype for function 'CreateSeekableStreams'
xpcom/tests/gtest/TestSlicedInputStream.cpp:125:20 [-Wmissing-prototypes] no previous prototype for function 'CreateNonSeekableStreams'
xpcom/tests/gtest/TestStrings.cpp:471:6 [-Wmissing-prototypes] no previous prototype for function 'test_assign_helper'
xpcom/tests/gtest/TestTArray.cpp:60:22 [-Wmissing-prototypes] no previous prototype for function 'DummyArray'
xpcom/tests/gtest/TestTArray.cpp:72:22 [-Wmissing-prototypes] no previous prototype for function 'FakeHugeArray'
xpcom/tests/gtest/TestThrottledEventQueue.cpp:96:6 [-Wmissing-prototypes] no previous prototype for function 'Enqueue'
xpcom/threads/BlockingResourceBase.cpp:86:6 [-Wmissing-prototypes] no previous prototype for function 'PrintCycle'
xpcom/threads/CPUUsageWatcher.cpp:41:10 [-Wmissing-prototypes] no previous prototype for function 'GetMicroseconds'
xpcom/threads/CPUUsageWatcher.cpp:46:10 [-Wmissing-prototypes] no previous prototype for function 'GetMicroseconds'
xpcom/threads/CPUUsageWatcher.cpp:51:40 [-Wmissing-prototypes] no previous prototype for function 'GetProcessCPUStats'
xpcom/threads/CPUUsageWatcher.cpp:80:40 [-Wmissing-prototypes] no previous prototype for function 'GetGlobalCPUStats'
xpcom/threads/nsTimerImpl.cpp:196:21 [-Wmissing-prototypes] no previous prototype for function 'GetTimerFiringsLog'
Differential Revision: https://phabricator.services.mozilla.com/D23264
--HG--
extra : rebase_source : e03df033209e0a08fc263603e78bc16a09467f15
extra : source : 3beec9fbfdedf346fff85309029e7805717958ac
Originally we stored the new information about installation defaults in
installs.ini since older versions of Firefox would throw away any new data in
profiles.ini any time they made changes to the profiles. That does however mean
we have to load two files on startup.
This changes things so that we save all the data in profiles.ini as well as a
version tag and still save the install data into installs.ini. An older version
will throw away the install data and version tag from profiles.ini but leave
installs.ini alone. On startup if the version tag is gone from profiles.ini then
we reload the install data from installs.ini and put it back into profiles.ini.
At some point in the future where we don't care about supporting older versions
of Firefox we can just drop installs.ini entirely.
A lot of the changes here involve moving to loading profiles.ini into an
in-memory ini, keeping it up to date and flushing it to disk. This means that we
no longer throw away any information in the ini file that this version does not
understand allowing the possibility of adding new data to this file in the
future.
Differential Revision: https://phabricator.services.mozilla.com/D22576
--HG--
extra : rebase_source : 9264bfebc7b0781ee903ef2772686d4cf920d1c9
extra : source : d4feb17faf013134f5eac8b5e19b714c56410973
Originally we stored the new information about installation defaults in
installs.ini since older versions of Firefox would throw away any new data in
profiles.ini any time they made changes to the profiles. That does however mean
we have to load two files on startup.
This changes things so that we save all the data in profiles.ini as well as a
version tag and still save the install data into installs.ini. An older version
will throw away the install data and version tag from profiles.ini but leave
installs.ini alone. On startup if the version tag is gone from profiles.ini then
we reload the install data from installs.ini and put it back into profiles.ini.
At some point in the future where we don't care about supporting older versions
of Firefox we can just drop installs.ini entirely.
A lot of the changes here involve moving to loading profiles.ini into an
in-memory ini, keeping it up to date and flushing it to disk. This means that we
no longer throw away any information in the ini file that this version does not
understand allowing the possibility of adding new data to this file in the
future.
Differential Revision: https://phabricator.services.mozilla.com/D22576
--HG--
extra : rebase_source : d097342b0c26fb92e5236e83035b87bb7da84321
This change sets up nsLocalFileWin to mirror the behavior of
nsLocalFileUnix, which is all-around more reasonable than the behavior
nsLocalFileWin had before. We also, in passing, fix up some unnecessary
error-handling code at the end of Create().
Depends on D22360
Differential Revision: https://phabricator.services.mozilla.com/D22361
--HG--
extra : moz-landing-system : lando
We eventually want to make the common path just attempt file creation,
and only fall back to creating all the ancestor directories if the
initial attempt failed. To do that in a reasonable way, we'll need
re-usable code for the creation code, which is what this patch creates.
Depends on D22359
Differential Revision: https://phabricator.services.mozilla.com/D22360
--HG--
extra : moz-landing-system : lando
Add a check that this array isn't using the static empty header before updating the size field.
Differential Revision: https://phabricator.services.mozilla.com/D22616
--HG--
extra : moz-landing-system : lando
This will allow devtools to clear cached error messages, like
we already can with ConsoleAPI messages.
Differential Revision: https://phabricator.services.mozilla.com/D21693
--HG--
extra : moz-landing-system : lando
If we are running a background thread in the launcher process to log failures,
then allowing the main thread to proceed with monkeypatching system calls is a
Bad Idea. This patch gives us an environment variable that, when set, indicates
that it is unsafe for PoisonIOInterposer to run.
This scenario is an uncommon one, but one that we must account for nonetheless.
Differential Revision: https://phabricator.services.mozilla.com/D21607
--HG--
extra : moz-landing-system : lando
Counting CPUs accesses the filesystem (sysfs or procfs), which we'd like
to disallow when sandboxed if possible, and fails silently if access
is denied. Because the CPU count rarely changes, this patch handles
that problem for the RDD process by caching a copy before starting
sandboxing.
Tested with a local patch to have the sandbox file broker client crash
if accessing the sysfs node for the CPU count, to verify that it's not
accessed.
Depends on D14524
Differential Revision: https://phabricator.services.mozilla.com/D20895
--HG--
extra : moz-landing-system : lando
This commit adds a `storage_variant::HashPropertyBag` type that
exposes an idiomatic Rust interface for `nsIWritablePropertyBag`.
Differential Revision: https://phabricator.services.mozilla.com/D21062
--HG--
extra : moz-landing-system : lando
If main thread is busy handling runnables in the normal priority queue, control-type of messages from
workers are possibly postponed to run after those. That can lead to bad performance, if the page
expects workers to be able to proceed simultanously with the main thread.
This patch makes the control messages to use medium high priority queue in order to try to
ensure they are handled in timely manner.
Pref dom.worker.use_medium_high_event_queue can be set to false to disable this new behavior.
Differential Revision: https://phabricator.services.mozilla.com/D22128
--HG--
extra : rebase_source : 447dec6dbcccaa0206a1815c21ccf713c523fc91
This patch tries to move them to `ContentParent` instead.
`ProcessPriorityManagerImpl::ObserveContentParentCreated` could not be moved
due to using `do_QueryInterface` to cast from a `nsISupports` down to the
`ContentParent` object. This could be fixed to remove the interfaces entirely,
but I left that for a follow-up.
Depends on D20549
Differential Revision: https://phabricator.services.mozilla.com/D20550
--HG--
extra : moz-landing-system : lando
This patch tries to move them to `ContentParent` instead.
`ProcessPriorityManagerImpl::ObserveContentParentCreated` could not be moved
due to using `do_QueryInterface` to cast from a `nsISupports` down to the
`ContentParent` object. This could be fixed to remove the interfaces entirely,
but I left that for a follow-up.
Depends on D20549
Differential Revision: https://phabricator.services.mozilla.com/D20550
--HG--
extra : moz-landing-system : lando
We should stop handling splitting nodes if mutation event listeners move or
remove the split nodes unexpectedly because the post processors may not be
able to keep handling the nodes. For example, if a node is moved to outside
of editing host, we shouldn't touch it anymore due to non-editable.
This patch makes `EditorBase::DoSplitNode()` return new error for making
any parent callers stop their job, but note that the following patch makes
any public methods expose the new error as exception for compatibility with
Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D20810
--HG--
extra : moz-landing-system : lando
nsSystemInfo is initialzied at first page load. Actually, content process uses
sync IPC to get Android OS information. But now, we can use Java code even if
on content process, so we should use JNI directly instead of sync IPC.
Also, nsSystemInfo still has unused extern android_sdk_version that is for
HoneyComp's DNS hack. So let's remote it.
Differential Revision: https://phabricator.services.mozilla.com/D20129
--HG--
extra : moz-landing-system : lando
This is more consistent with what the Rust bits of the style system do, and
removes a pointer from ComputedStyle which is always nice.
This also aligns the Rust bits with the C++ bits re. not treating xul pseudos as
anonymous boxes. See the comment in nsTreeStyleCache.cpp regarding those.
Can't wait for XUL trees to die.
Depends on D19001
Differential Revision: https://phabricator.services.mozilla.com/D19002
--HG--
extra : moz-landing-system : lando
The actual subcategories will be added in later patches, so that there are no
unused categories.
Differential Revision: https://phabricator.services.mozilla.com/D11334
--HG--
extra : moz-landing-system : lando
We need to preprocess these files so we can eventually add unwind
information, for which we need to include C headers.
Differential Revision: https://phabricator.services.mozilla.com/D19819
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
This is a follow-up to the previous part, which actually changes one of
these callers to use Array<nsIIDRef> instead of [array] nsIIDPtr.
From doing this patch, it seems like we should consider changing
the type `nsIIDRef` to instead simply be `nsIID`, and treat it more like
the `AString` types from the POV of XPIDL. `nsIIDPtr` would then
continue to exist for backwards compatibility, but we can probably
remove almost all current consumers over time.
Depends on D19175
Differential Revision: https://phabricator.services.mozilla.com/D19176
--HG--
extra : moz-landing-system : lando
Currently the [ref] and [ptr] types share the same underlying
implementation. This is unfortunate, and can cause correctness problems
with outparam refs (as an example).
By using the same tools used to allow other larger objects (such as
jsid, nsTArray, and nsString) to be stored directly in the nsXPTCVariant
object, this patch directly stores the nsID in the nsXPTCVariant object
when calling from JS into C++.
Using this new strategy avoids an nsID* allocation every time we pass
one over XPConnect, and should also allow us to simplify callers.
In addition, some special casing is added to xpidl to make it possible
to use the nsid reference type objects directly inside of Array<T>,
which will allow us to remove `[array] nsIIDPtr` callers.
Differential Revision: https://phabricator.services.mozilla.com/D19175
--HG--
extra : moz-landing-system : lando
Define a new RAII class, AutoDebuggerJobQueueInterruption, to save and restore
the current ECMAScript job queue, to protect the debuggee's job queue from
activity that occurs in debugger callbacks. Add a new method to the JS::JobQueue
abstract base class, saveJobQueue, to support AutoDebuggerJobQueueInterruption.
Comments on AutoDebuggerJobQueueInterruption provide details.
Implement saveJobQueue for SpiderMonkey's internal job queue and for Gecko's job
queue in CycleCollectedJSContext.
Differential Revision: https://phabricator.services.mozilla.com/D17546
--HG--
extra : moz-landing-system : lando
While the behavior of ECMAScript Promises and their associated job queue is
covered by the ECMAScript standard, the HTML specification amends that with
additional behavior the web platform requires. To support this, SpiderMonkey
provides hooks the embedding can set to replace SpiderMonkey's queue with its
own implementation.
At present, these hooks are C-style function-pointer-and-void-pointer pairs,
which are awkward to handle and mistake-prone, as passing a function the wrong
void* is not a type error. Later patches in this series must add new hooks,
making a bad situation worse.
A C++ abstract base class is a well-typed alternative. This introduces a new
`JS::JobQueue` abstract class, and adapts SpiderMonkey's internal job queue and
Gecko's customization to use it. `GetIncumbentGlobalCallback` and
`EnqueuePromiseJobCallback` become virtual methods.
Within SpiderMonkey, the patch gathers the various fields of JSContext that
implement the internal queue into their own type, js::InternalJobQueue. Various
jsfriendapi functions become veneers for calls to methods specific to the
derived class. The InternalJobQueue type itself remains private to SpiderMonkey,
as it uses types like TraceableFifo, derived from Fifo, that are not part of
SpiderMonkey's public API.
Within Gecko, CycleCollectedJSContext acquires JS::JobQueue as a private base
class, and a few static methods are cleaned up nicely.
There are a few other hooks defined in js/public/Promise.h that might make sense
to turn into virtual methods on JobQueue. For example,
DispatchToEventLoopCallback, used for resolving promises of results from
off-main-thread tasks, is probably necessarily connected to the JobQueue
implementation in use, so it might not be sensible to set one without the other.
But it was left unchanged to reduce this patch's size.
Differential Revision: https://phabricator.services.mozilla.com/D17544
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
With most of the JS components converted to static registration, the string
arena and component hashtables are much smaller than the minimum space we
allocate for them.
Differential Revision: https://phabricator.services.mozilla.com/D18474
--HG--
extra : source : 81dc12cc9257ba9c8f2eef578d99b142220b37a3
extra : histedit_source : 6f64bcd954cbc4db6970acfb5ed81717c739d13f
This commit hooks up nsFrameLoader in the child process to use the
PRemoteFrame protocol to support remote iframes. This is only activated
when a special pref is set, and the iframe has a marker attribute on it.
For example:
<iframe fission/>
In the future, we should unify nsFrameLoader to operate on a common
interface between the parent process top-level browser, and child
process subframe case. This commit just adds a new member that can
be used instead of mRemoteBrowser, when appropriate. IsRemoteFrame()
will return true for both cases.
Differential Revision: https://phabricator.services.mozilla.com/D17444
--HG--
extra : source : e33b9de7283e5fb6441e118b25af8d4ac3411bf2
extra : intermediate-source : 697a9159e0d260118ee6ebd34948d187a8c5359f
The only difference between ShutdownLoaders and ShutdownFinal was an observer service shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D18389
--HG--
extra : moz-landing-system : lando
The basic idea for the changes around UnwrapObjectInternal and its callers
(UnwrapObject, UNWRAP_OBJECT, etc) is to add a parameter to the guts of the
object-unwrapping code in bindings which can be either a JSContext* or nullptr
(statically typed). Then we test which type it is and do either a
CheckedUnwrapDynamic or CheckedUnwrapStatic. Since the type is known at
compile time, there is no actual runtime check; the compiler just emits a call
to the right thing directly (verified by examining the assembly output on
Linux).
The rest of the changes are mostly propagating through that template parameter,
adding static asserts to make sure people don't accidentally pass nullptr while
trying to unwrap to a type that might be a WindowProxy or Location, etc.
There are also some changes to places that were calling CheckedUnwrap directly
to use either the static or dynamic version, as needed.
Differential Revision: https://phabricator.services.mozilla.com/D17883
--HG--
extra : moz-landing-system : lando
The basic idea for the changes around UnwrapObjectInternal and its callers
(UnwrapObject, UNWRAP_OBJECT, etc) is to add a parameter to the guts of the
object-unwrapping code in bindings which can be either a JSContext* or nullptr
(statically typed). Then we test which type it is and do either a
CheckedUnwrapDynamic or CheckedUnwrapStatic. Since the type is known at
compile time, there is no actual runtime check; the compiler just emits a call
to the right thing directly (verified by examining the assembly output on
Linux).
The rest of the changes are mostly propagating through that template parameter,
adding static asserts to make sure people don't accidentally pass nullptr while
trying to unwrap to a type that might be a WindowProxy or Location, etc.
There are also some changes to places that were calling CheckedUnwrap directly
to use either the static or dynamic version, as needed.
Differential Revision: https://phabricator.services.mozilla.com/D17883
--HG--
extra : moz-landing-system : lando
The basic idea for the changes around UnwrapObjectInternal and its callers
(UnwrapObject, UNWRAP_OBJECT, etc) is to add a parameter to the guts of the
object-unwrapping code in bindings which can be either a JSContext* or nullptr
(statically typed). Then we test which type it is and do either a
CheckedUnwrapDynamic or CheckedUnwrapStatic. Since the type is known at
compile time, there is no actual runtime check; the compiler just emits a call
to the right thing directly (verified by examining the assembly output on
Linux).
The rest of the changes are mostly propagating through that template parameter,
adding static asserts to make sure people don't accidentally pass nullptr while
trying to unwrap to a type that might be a WindowProxy or Location, etc.
There are also some changes to places that were calling CheckedUnwrap directly
to use either the static or dynamic version, as needed.
Differential Revision: https://phabricator.services.mozilla.com/D17883
--HG--
extra : moz-landing-system : lando
Old Confluence does not aware of conflated model keypress event (see UI Events
spec, https://w3c.github.io/uievents/#determine-keypress-keyCode).
Additionally, Confluence can be hosted with any domains. Therefore, we cannot
use blacklist to disable the conflated model keypress event only on it.
This patch checks whether current or parent document is Confluence with JS
module, called KeyPressEventModelCheckerChild. For kicking this module,
nsHTMLDocument dispatches an custom event, CheckKeyPressEventModel, when it
becomes editable only first time. Finally, if it's a Confluence instance, the
module let PresShell know that we need to use split model keypress event in it.
Differential Revision: https://phabricator.services.mozilla.com/D17907
--HG--
extra : moz-landing-system : lando
Gecko Profiler uses DWARF information to get stack. But xptcall assembler for
Android/aarch64 doesn't have CFI directive, so it cannot walk stack well.
Differential Revision: https://phabricator.services.mozilla.com/D18335
--HG--
extra : moz-landing-system : lando
The total size of an IPC inputStream message must be less than 1mb. When we
compose the message for the multiplex stream, each sub stream collaborates with
its own size, deciding if it's better to be a pipe stream (IPCRemoteStream) or
a full serialized one.
Differential Revision: https://phabricator.services.mozilla.com/D18543
--HG--
extra : moz-landing-system : lando
It relies on AC_TRY_RUN, which doesn't work on cross-compiles. What this
means is that the feature has been disabled on mac builds on automation
ever since we switched to cross-compiles. It's still enabled on local
mac builds because the test runs there, and returns "yes". It also means
it's disabled on Android, where it probably works (at least debug tests
on try don't complain).
It also doesn't currently run on Windows because it's in a skipped
section on Windows, but if moved out of that section, the test returns
"no".
So, we remove any configure test for the feature, in favor of
preprocessor checks in nsTraceRefcnt.cpp.
Depends on D18055
Differential Revision: https://phabricator.services.mozilla.com/D18056
--HG--
extra : moz-landing-system : lando
RecordedTextureData records TextureData calls for play back in the GPU process.
CanvasChild and CanvasParent set up the recorder and translator.
They also help to manage the starting of translation and co-ordinating the
translation with the frame transactions.
This patch also includes other changes to wire up recording and playback.
Found when forcing a non-unified build of the Gecko Profiler:
- "nsError.h" needed to define `nsresult`.
- "nsStringFwd.h" needed to declare `nsAString` and `nsACString`.
Differential Revision: https://phabricator.services.mozilla.com/D18621
--HG--
extra : moz-landing-system : lando
The only difference between ShutdownLoaders and ShutdownFinal was an observer service shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D18389
--HG--
extra : moz-landing-system : lando
Give nsIStringStream separate SizeOfIncludingThisIfUnshared and SizeOfIncludingThisEvenIfShared methods. Use the former for memory reporting and the latter for JS engine memory accounting.
Differential Revision: https://phabricator.services.mozilla.com/D29336
We already take steps in `IndexOf` to avoid bounds checks--by using
direct pointer accesses--and we should do the same thing for binary
searches as well.
ProcessTypeRequiresWinEventHook was added when attempting to turn on win32k
lockdown for GMP processes. Having a less specific, but globally accessible,
function will make it more useful while applying win32k lockdown to other
process types.
Before this set of patches, the decision of exposing the stream as a pipe was
centralized in IPCStreamUtils, based on the total expectation size of the IPC
message. This triggers issues when multiplex inputStreams contain something
that cannot be sent as a pipe (IPCBlobInputStream, for instance), or something
that it's better to do not set as a pipe (nsFileInputStream), together with
memory streams (nsStringInputStream), which could make the IPC message greater
then what accepted (1mb).
These patches move the "pipe vs non-pipe" choice into the single inputStream
implementation.
In order to test the test harness's handling of a process failing to
produce a leak log, add a special function that disables the bloat log
output.
Differential Revision: https://phabricator.services.mozilla.com/D17534
--HG--
extra : moz-landing-system : lando
Don't warn about measurements that aren't available for the current platform.
Differential Revision: https://phabricator.services.mozilla.com/D17862
--HG--
extra : moz-landing-system : lando
This changes the policy to use the pref and permissions rather than a boolean flag. Using permissions gets us proper settings on startup without introducing any new overhead. Going this way flips our tests around so rather than testing an override to turn off private browsing support, we test overrides to enable private browsing support.
Differential Revision: https://phabricator.services.mozilla.com/D14482
--HG--
extra : moz-landing-system : lando
This patch removes the datetimebox binding and always use
UA Widget for the job.
Depends on D17571
Differential Revision: https://phabricator.services.mozilla.com/D17572
--HG--
extra : moz-landing-system : lando
This patch removes the XBL videocontrols binding and make <video>
to always use the UA Widget to generate controls.
DevTools tests that look for NAC is switched to use <input type=file>.
Differential Revision: https://phabricator.services.mozilla.com/D17571
--HG--
extra : moz-landing-system : lando
***
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
We lose some sugar but gain some safety. This seems like the right
trade. If people want sugar they should use Rust.
Differential Revision: https://phabricator.services.mozilla.com/D16918
--HG--
extra : moz-landing-system : lando
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
--HG--
extra : moz-landing-system : lando
Just because we're calling into the component manager for a service
doesn't mean that we're on a thread that has an associated event loop to
spin. If we are lacking such an event loop, we shouldn't try to
NS_ProcessNextEvent, because that will wind up asserting that there's no
event queue. Instead, just yield with the expectation that some other
thread is making progress on constructing the service that we want.
I'm always forgetting which code path is which. So give both these
functions clearer names that say if they're used by profiling or telemetry.
--HG--
extra : rebase_source : 8edcabba510bcf7170b7e071f7cb3a21be23b0e4
This is a better place for it and is more appropriate given that it
already exports to mozilla/DataMutex.h. I'll fix the rvalue reference
problems in a follow up.
Differential Revision: https://phabricator.services.mozilla.com/D16723
--HG--
rename : dom/media/eme/DataMutex.h => xpcom/threads/DataMutex.h
extra : moz-landing-system : lando
This patch implements -moz-gtk-csd-hide-titlebar-by-default media query
to check if the system titlebar should be disabled by default on Linux systems
(it's already disabled on Window/Mac).
It also removes explicit definition of browser.tabs.drawInTitlebar preference on Linux.
When browser.tabs.drawInTitlebar is missing the -moz-gtk-csd-hide-titlebar-by-default
is used to obtain the titlebar state. When browser.tabs.drawInTitlebar is set
in about:config or by Customize menu, the user peference is used instead of the default.
It also fixes a -moz-gtk-csd-available media query,
it was always true regardless the actual system setting.
Differential Revision: https://phabricator.services.mozilla.com/D16036
--HG--
extra : moz-landing-system : lando
This patch implements -moz-gtk-csd-hide-titlebar-by-default media query
to check if the system titlebar should be disabled by default on Linux systems
(it's already disabled on Window/Mac).
It also removes explicit definition of browser.tabs.drawInTitlebar preference on Linux.
When browser.tabs.drawInTitlebar is missing the -moz-gtk-csd-hide-titlebar-by-default
is used to obtain the titlebar state. When browser.tabs.drawInTitlebar is set
in about:config or by Customize menu, the user peference is used instead of the default.
It also fixes a -moz-gtk-csd-available media query,
it was always true regardless the actual system setting.
Differential Revision: https://phabricator.services.mozilla.com/D16036
--HG--
extra : moz-landing-system : lando
Currently nsAppRunner is responsible for choosing or creating a profile to use
at startup. It then has to create a reset profile if necessary and lock the
selected profile directories. But these latter things are done in different
places of the selection code and done in different ways, sometimes we delay
while trying to get the lock, sometimes we don't.
This patch moves the profile selection part of the code to its own function so
that then we only have to have one place that does the profile reset and
locking logic.
It makes a lot of sense to have the selection code live in the profile service.
It can use information from the database load to help make the choices and it
also means that we can expose the profile selection code through xpcom allowing
it to be easily automatically tested. It will also be more important for future
patches for the dedicated profiles feature.
Differential Revision: https://phabricator.services.mozilla.com/D16116
--HG--
extra : moz-landing-system : lando
To setup memory reporter on socket process, this patch modifies the PSocketProcess protocol to implement the same memory reporting functions as the PContent and PGPU protocols.
Differential Revision: https://phabricator.services.mozilla.com/D14155
--HG--
extra : moz-landing-system : lando
AsyncWaitRunnable holds a strong reference to its stream, and
NonBlockingAsyncInputStream holds a strong reference to the
runnable. The cycle gets broken in the RunAsyncWaitCallback() method
of the stream, but if the runnable is cancelled then we leak them
both. This patch fixes that by clearing the pointer to the stream when
the runnable is cancelled, breaking the cycle.
Differential Revision: https://phabricator.services.mozilla.com/D16248
--HG--
extra : moz-landing-system : lando
AsyncWaitRunnable holds a strong reference to its stream, and
NonBlockingAsyncInputStream holds a strong reference to the
runnable. The cycle gets broken in the RunAsyncWaitCallback() method
of the stream, but if the runnable is cancelled then we leak them
both. This patch fixes that by clearing the pointer to the stream when
the runnable is cancelled, breaking the cycle.
Differential Revision: https://phabricator.services.mozilla.com/D16248
--HG--
extra : moz-landing-system : lando
To setup memory reporter on socket process, this patch modifies the PSocketProcess protocol to implement the same memory reporting functions as the PContent and PGPU protocols.
Differential Revision: https://phabricator.services.mozilla.com/D14155
--HG--
extra : moz-landing-system : lando
The only visible change from this change is that telemetry will be
discontinuous. The owners for the relevant telemetry probes have
reviewed this and indicated that this discontinuity is OK.
The static XPCOM manifest format makes it easy to define a component in a
single place, without separate contract ID and CID macro definitions in
headers, and variable constants in module files. Without any other changes,
however, those macros are still required in order to create instances of or
retrieve services for the component.
This patch solves that problem by allowing component definitions to include an
explicit component name, and adding helpers for each named component to
Components.h:
mozilla::components::<Name>::CID() to retrieve its class ID.
mozilla::components::<Name>::Create() to create a new instance.
mozilla::components::<Name>::Service() to retrieve its service instance.
These getters have the benefit of doing full compile-time sanity checking,
with no possibilty of using a mistyped contract ID string, or a macro constant
which has gotten out of sync with the component entry.
Moreover, when possible, these getters are optimized to operate on module
entries directly, without going through expensive hash lookups or virtual
calls.
Differential Revision: https://phabricator.services.mozilla.com/D15037
--HG--
extra : rebase_source : ab07ef6a7ad8b26cd4e1901d3365beeb8c22ec3b
extra : source : 929fd654c9dfc3222e1972faadea3cc066e51654
We have tons of code in the component manager which stringifies nsIDs so that
it can print the result. The standard stringification process is pretty
bloated, and makes the code difficult to update. And, frankly, I mostly just
got tired of copying it around.
This patch adds a helper which stringifies a nsID to a nsAutoCString, which
can be used as a temporary value in a single statement, rather than requiring
a separate local variable and function call for each operation.
Differential Revision: https://phabricator.services.mozilla.com/D15036
--HG--
extra : rebase_source : 98dbd9dfa78b2f9d5cdab48e1c61e085bf7081c9
extra : source : 1ddd80d9e91a17c01f0a8a73036810042a0ab080
This patch essentially creates a separate, static component database for
statically-defined CID and contract ID entries, and gives it precedence over
the runtime DB. It combines the two separate databases by updating existing
code to use lookup functions which understand both databases, and then access
all entries through wrappers which defer to the appropriate underlying type.
Static component entries require no runtime relocations, and require no
writable data allocation aside from one pointer-sized BSS entry per CID, and
one bit of BSS per contract ID.
To achieve this, all strings in the static lookup tables are stored as indexes
into a static string table, all constructor functions live in a switch
statement which compiles to a relative jump table, and all writable data for
static entries is accessed by indexed lookups into BSS arrays.
We also avoid creating nsIFactory entries for static components when possible
by adding a CreateInstance method to nsFactoryEntry and the corresponding
entry wrapper to directly call the appropriate constructor method, and only
create a factory object when required by external code.
Differential Revision: https://phabricator.services.mozilla.com/D15035
--HG--
extra : rebase_source : 903a6f31c6290d0090e6765e0e317d1f749c5855
extra : source : b8d2dfdfc324c53ce5aacc822ce52d4e2bfdc31a
The static XPCOM manifest format makes it easy to define a component in a
single place, without separate contract ID and CID macro definitions in
headers, and variable constants in module files. Without any other changes,
however, those macros are still required in order to create instances of or
retrieve services for the component.
This patch solves that problem by allowing component definitions to include an
explicit component name, and adding helpers for each named component to
Components.h:
mozilla::components::<Name>::CID() to retrieve its class ID.
mozilla::components::<Name>::Create() to create a new instance.
mozilla::components::<Name>::Service() to retrieve its service instance.
These getters have the benefit of doing full compile-time sanity checking,
with no possibilty of using a mistyped contract ID string, or a macro constant
which has gotten out of sync with the component entry.
Moreover, when possible, these getters are optimized to operate on module
entries directly, without going through expensive hash lookups or virtual
calls.
Differential Revision: https://phabricator.services.mozilla.com/D15037
--HG--
extra : rebase_source : db7fe00fe80677a6a42d8136fd4505a02e330495
extra : absorb_source : ec11e22825befcd6fa4e96ffa81cd1c1b23e3bef
extra : histedit_source : 650e8e98235df5d757f3fa725bad390e9c094c34
We have tons of code in the component manager which stringifies nsIDs so that
it can print the result. The standard stringification process is pretty
bloated, and makes the code difficult to update. And, frankly, I mostly just
got tired of copying it around.
This patch adds a helper which stringifies a nsID to a nsAutoCString, which
can be used as a temporary value in a single statement, rather than requiring
a separate local variable and function call for each operation.
Differential Revision: https://phabricator.services.mozilla.com/D15036
--HG--
extra : rebase_source : 4a1971289bbf6abb42da30d024b30a81f7a0ca06
extra : absorb_source : 11318729edd01e7fc6bdbcc66346fdbf23e385ba
extra : histedit_source : c9a16f6e23c391813cfc3ce3fc82c835db0c46d6
This patch essentially creates a separate, static component database for
statically-defined CID and contract ID entries, and gives it precedence over
the runtime DB. It combines the two separate databases by updating existing
code to use lookup functions which understand both databases, and then access
all entries through wrappers which defer to the appropriate underlying type.
Static component entries require no runtime relocations, and require no
writable data allocation aside from one pointer-sized BSS entry per CID, and
one bit of BSS per contract ID.
To achieve this, all strings in the static lookup tables are stored as indexes
into a static string table, all constructor functions live in a switch
statement which compiles to a relative jump table, and all writable data for
static entries is accessed by indexed lookups into BSS arrays.
We also avoid creating nsIFactory entries for static components when possible
by adding a CreateInstance method to nsFactoryEntry and the corresponding
entry wrapper to directly call the appropriate constructor method, and only
create a factory object when required by external code.
Differential Revision: https://phabricator.services.mozilla.com/D15035
--HG--
extra : rebase_source : 8d02ff3b67b8078d1ac837d8c12f54786155c6b6
extra : absorb_source : 0fe36ca220c9270e634abf5b1f320a01878e0ce7
extra : histedit_source : 51521ceae2c1b3e4e8bf63d4ed1e2e67e9468780
Currently, when we build the component registry at startup, we exclude any
entry with a process selector which doesn't match the current process. When we
switch to static lookup tables, however, that check is going to have to happen
for every lookup, since we can't alter the table at runtime.
That may not matter much, given how expensive the rest of the component lookup
code is relative to ProcessMatchesSelector, but it's also easy and cheap
enough to generate a lookup table for all possible ProcessSelector values, and
do a quick index check instead.
Differential Revision: https://phabricator.services.mozilla.com/D15033
--HG--
extra : rebase_source : 33bb395f3eaa6522b18dbdb6e415b5287add86cd
extra : source : dd00365ebb55a06b4d6896bc86dd0fc94482d805
The current implementations of GetService are slightly different for contract
IDs than they are for CIDs, but I'm pretty sure that's unintentional.
This patch factors out the common parts of the two implementations, which
should prevent them from diverging in the future, and avoids the need to make
the same changes in multiple places in the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D15032
--HG--
extra : rebase_source : fceab9df2879f8e02c81009ab3d8c754c9f14677
extra : source : 538e40c5ee1336a7ba467f0f4128dcddf97ef75d
Currently, when we build the component registry at startup, we exclude any
entry with a process selector which doesn't match the current process. When we
switch to static lookup tables, however, that check is going to have to happen
for every lookup, since we can't alter the table at runtime.
That may not matter much, given how expensive the rest of the component lookup
code is relative to ProcessMatchesSelector, but it's also easy and cheap
enough to generate a lookup table for all possible ProcessSelector values, and
do a quick index check instead.
Differential Revision: https://phabricator.services.mozilla.com/D15033
--HG--
extra : rebase_source : fa6c764c2acd68dbe620e5a0779c6c58724ea209
The current implementations of GetService are slightly different for contract
IDs than they are for CIDs, but I'm pretty sure that's unintentional.
This patch factors out the common parts of the two implementations, which
should prevent them from diverging in the future, and avoids the need to make
the same changes in multiple places in the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D15032
--HG--
extra : rebase_source : 591d854d604dc7597dbfe5438bfbd0af98224c5b
nsTimerEvent goes through a multi-step initialization for reasons that
are lost to time. We are also seeing peculiar crashes in
`nsTimerEvent::SetTimer()` that are only explainable by `SetTimer`
finding a non-null pointer where there should have been a null pointer.
The compiler ought to have been able to optimize those bits away, but no
matter: we can do the job ourselves and make the code clearer.
Since we only call `SetTimer` once, we should just move its work into
nsTimerEvent's constructor.
Doing this code movement separately will ideally make the next part of
this work easier to review. The idea is that we want to extract all the
necessary information from `timer` before we pass ownership of it into
the newly-allocated nsTimerEvent.
Unlike many of our uses of `new`, nsTimerEvent has its own definition of
`operator new`, to ensure instances are allocated through
TimerEventAllocator. And allocating with TimerEventAllocator can fail.
Later changes, however, want to assume that constructing an nsTimerEvent
can't fail, which is difficult to guarantee with the current structure.
To make that guarantee, we need to make explicit what calling `new`
does: there's an "allocate memory" step and a "construct the object"
step. The first part can fail, and that's what we care about here.
Once we have a chunk of memory, we can construct the object as normal,
secure in the knowledge that calling (placement) `new` is now guaranteed
to succeed.
The layout module initializes a bunch of things, specifically
XPConnect. And if we're not loading chrome manifests, we shouldn't need
to initialize the layout module.
Checking that the current process type is not equal to some value
requires adding code when new process types are added. Since it seems
reasonable to assume that all new process types aren't going to require
chrome manifests, let's make the code reflect that assumption as well,
and reduce the number of places you need to touch when adding a new
process type.
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
This will be needed for the next patches since the cast from nsIDocument* to
nsISupports* will become ambiguous, and I don't really want to replace all users
of nsCOMPtr<nsIDocument> with RefPtr.
We have ToSupports to handle this, so use it.
Differential Revision: https://phabricator.services.mozilla.com/D15350
Jeff Walden
Sylvestre Ledru
Csoregi Natalia
Narcis Beleuzu
Nathan Froyd
Andrew McCreight
Ciure Andrei
Randall E. Barker
Dave Townsend
Daniel Varga
Brindusan Cristian
Petr Sumbera
Daosheng Mu
Andrew Osmond
Eden Chuang
Honza Bambas
Jeff Gilbert
Gerald Squelart
Jonathan Kew
Philip Chimento
Cameron McCormack
Olli Pettay
Oana Pop Rus
Boris Zbarsky
Mark Banner
Haik Aftandilian
Noemi Erli
Cosmin Sabou
Mats Palmgren
Emilio Cobos Álvarez
shindli
Nika Layzell
Kirk Steuber
arthur.iakab
Lina Cambridge
Doug Thayer
Nicholas Nethercote
Mark Goodwin
Andreea Pavel
Valentin Gosu
Alex Gaynor
Gabriele Svelto
ffxbld
Chris Peterson
Andrea Marchesini
David Major
Chris Pearce
Nathan Froyd
Florian Quèze
Eric Rahm
Masatoshi Kimura
Brian Hackett
Coroiu Cristina
Yaron Tausky
Gurzau Raul
Nicolas Chevobbe
Razvan Maries
Gijs Kruitbosch
Aaron Klotz
Peter Van der Beken
Jed Davis
Ryan Hunt
Karl Tomlinson
Masayuki Nakano
Makoto Kato
Bogdan Tara
Markus Stange
Michael Cooper
Mike Hommey
Jim Blandy
Jonathan Kingston
Kris Maglione
Myk Melez
Adrian Wielgosik
Bob Owen
Bren Louis
Jon Coppeard
Sebastian Hengst
Randell Jesup
Dorel Luca
Dana Keeler
Shane Caraveo
Timothy Guan-tin Chien
James Willcox
Jeff Muizelaar
Greg Tatum
Martin Stransky
Andy Wingo
Ehsan Akhgari
Paul Bone
Henri Sivonen
Dragana Damjanovic
xftroxgpx
Kershaw Chang
Jan de Mooij
bitnotri