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
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
