Adds GeckoChildProcessHost::GetAll() and use it in ChromeUtils::GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D33920
--HG--
extra : moz-landing-system : lando
In particular:
* trait objects without an explicit `dyn` are deprecated
* `...` range patterns are deprecated
I think these shouldn't really warn by default and should be clippy / opt-in
lints, but anyway, doesn't hurt.
Differential Revision: https://phabricator.services.mozilla.com/D35135
--HG--
extra : moz-landing-system : lando
Both for symmetry with other string APIs, and also to prevent footguns (since I
debugged for a while a typo where I wrote nsGkAtoms::empty rather than
nsGkAtoms::_empty).
We could use null here, but that will not be possible in the future when I use
the rust representation of more grid data structures (at least without
increasing memory usage).
So I think I'll keep using ::_empty as a signaling value for "no grid
identifier".
Differential Revision: https://phabricator.services.mozilla.com/D35120
--HG--
extra : moz-landing-system : lando
Adds GeckoChildProcessHost::GetAll() and use it in ChromeUtils::GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D33920
--HG--
extra : moz-landing-system : lando
This uses GetPerformanceInformation() to measure how much commit space is
available globally. Previously we relied on GlobalMemoryStatusEx() but in
spite of the function name the commit-space values it returns are
*per process* and thus unreliable. Available physical memory measurement has
also been removed since it was never used and we don't plan on using it
anytime soon.
Differential Revision: https://phabricator.services.mozilla.com/D35018
--HG--
extra : moz-landing-system : lando
The approach isn't perhaps super elegant, but it is a small and simple tweak.
Differential Revision: https://phabricator.services.mozilla.com/D34923
--HG--
extra : moz-landing-system : lando
Change the Mac GMP process launch to include sandboxing params on the command line to allow the sandbox to be started earlier during GMP process launch. Content, extension, and RDD processes have already been changed to start the sandbox earlier.
Update GMPProcessParent to override GeckoChildProcessHost methods used to construct sandboxing parameters. Pass the plugin path as a sandbox parameter so that the sandbox rules can whitelist the plugin directory which is now read after the sandbox is enabled in the plugin process. On development builds, pass "testingReadPath" params so directories needed during automated tests can be whitelisted.
Update Mac sandboxing code to detect GMP sandbox params on the command line and enable the sandbox with additional arguments needed for early sandbox start.
Allow reverting to the old implementation by setting security.sandbox.gmp.mac.earlyinit to false.
Differential Revision: https://phabricator.services.mozilla.com/D34085
--HG--
extra : moz-landing-system : lando
Change the Mac GMP process launch to include sandboxing params on the command line to allow the sandbox to be started earlier during GMP process launch. Content, extension, and RDD processes have already been changed to start the sandbox earlier.
Update GMPProcessParent to override GeckoChildProcessHost methods used to construct sandboxing parameters. Pass the plugin path as a sandbox parameter so that the sandbox rules can whitelist the plugin directory which is now read after the sandbox is enabled in the plugin process. On development builds, pass "testingReadPath" params so directories needed during automated tests can be whitelisted.
Update Mac sandboxing code to detect GMP sandbox params on the command line and enable the sandbox with additional arguments needed for early sandbox start.
Allow reverting to the old implementation by setting security.sandbox.gmp.mac.earlyinit to false.
Differential Revision: https://phabricator.services.mozilla.com/D34085
--HG--
extra : moz-landing-system : lando
The first test does not really need to check that we spend less than
200ms, and we can give more time to the scheduler in the second
test, as long as we check that is less than the recursive dispatched
event
Differential Revision: https://phabricator.services.mozilla.com/D34988
--HG--
extra : moz-landing-system : lando
Remove the mozpersist attribute and XULDocument requirement to use XUL
persistence and allow any system privilege document to use it by default.
Differential Revision: https://phabricator.services.mozilla.com/D34602
--HG--
extra : moz-landing-system : lando
Change the Mac GMP process launch to include sandboxing params on the command line to allow the sandbox to be started earlier during GMP process launch. Content, extension, and RDD processes have already been changed to start the sandbox earlier.
Update GMPProcessParent to override GeckoChildProcessHost methods used to construct sandboxing parameters. Pass the plugin path as a sandbox parameter so that the sandbox rules can whitelist the plugin directory which is now read after the sandbox is enabled in the plugin process. On development builds, pass "testingReadPath" params so directories needed during automated tests can be whitelisted.
Update Mac sandboxing code to detect GMP sandbox params on the command line and enable the sandbox with additional arguments needed for early sandbox start.
Allow reverting to the old implementation by setting security.sandbox.gmp.mac.earlyinit to false.
Differential Revision: https://phabricator.services.mozilla.com/D34085
--HG--
extra : moz-landing-system : lando
Change the Mac GMP process launch to include sandboxing params on the command line to allow the sandbox to be started earlier during GMP process launch. Content, extension, and RDD processes have already been changed to start the sandbox earlier.
Update GMPProcessParent to override GeckoChildProcessHost methods used to construct sandboxing parameters. Pass the plugin path as a sandbox parameter so that the sandbox rules can whitelist the plugin directory which is now read after the sandbox is enabled in the plugin process. On development builds, pass "testingReadPath" params so directories needed during automated tests can be whitelisted.
Update Mac sandboxing code to detect GMP sandbox params on the command line and enable the sandbox with additional arguments needed for early sandbox start.
Allow reverting to the old implementation by setting security.sandbox.gmp.mac.earlyinit to false.
Differential Revision: https://phabricator.services.mozilla.com/D34085
--HG--
extra : moz-landing-system : lando
In particular, on Windows stdin/out/err may not be associated with a stream
(e.g., app without console window), in which case _get_osfhandle() returns -2.
Differential Revision: https://phabricator.services.mozilla.com/D34513
--HG--
extra : moz-landing-system : lando
This patch takes the approach to count up to 100 wakeups and reports then time it took for that period. Regression in wakeups could
show up as decreased mean or median time.
Differential Revision: https://phabricator.services.mozilla.com/D32543
--HG--
extra : moz-landing-system : lando
This patch also contains some other cleanups to avoid the need for
special-casing getting symbol IDs at call-sites.
Differential Revision: https://phabricator.services.mozilla.com/D33543
--HG--
extra : moz-landing-system : lando
When comparing compatibility versions we first compare the version part. If that
shows us to be a downgrade then we stop checking at that point. But we must also
stop checking if it shows us to be an upgrade since we don't need to check the
build IDs at that point. This also applies to the check for the app build ID.
This means that a newer version with an older build id will appear to be a
downgrade.
This is problematic for safe mode because when safe mode runs it sets the
compatibility version to "Safe Mode" (bug 1556831) to ensure that caches are
invalidated on next startup. On the next run the Firefox version is considered
as newer than "Safe Mode" so we would move on to comparing the build IDs. But
the Firefox build ID gets version compared to "" (since there isn't a build ID
part in "Safe Mode"). Since build ID's are larger than 32-bit numbers we trigger
bug 1556829 and the actual comparison depends on the value of the build ID
truncated to 32-bits. This seems to often be negative and so lower than the
apparent previous build ID causing us to think this is a downgrade.
Cue nfroydnj saying I told you so because if I'd written this as a more
traditional compare function as he suggested I probably would have caught this.
Differential Revision: https://phabricator.services.mozilla.com/D33702
--HG--
extra : rebase_source : bb506c4ba4d75a68976bb114015d53cd41b4d4c3
When we're lowering extra types (e.g. array element types) and we find
that we haven't already lowered the type, we say that the new type is
going to live at the end of the `types` array. But we don't append a
new type (i.e. filling in the entry) until after we call `lower_type`,
which means that some other call to `lower_extra_type` might find
that *its* new type will live at the same position we "allocated" higher
up on the stack.
We don't appear to run into this issue, as the only nested array types
are things like `Array<Array<uint8>>`, and `uint8` is guaranteed to
already have been lowered. But if people start doing more complicated
things, we're bound to run into this sooner or later.
Differential Revision: https://phabricator.services.mozilla.com/D33299
--HG--
extra : moz-landing-system : lando
This is similar to this Chromium change:
https://codereview.chromium.org/1155353002
The editing spec doesn't mention editing non-HTML documents, and historically
this is only a feature that WebKit has supported. Supporting this feature
increases the attack surface of the browser without a clear benefit, so it
seems like a good idea to converge on this behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D32913
--HG--
rename : testing/web-platform/tests/html/editing/editing-0/making-entire-documents-editable-the-designmode-idl-attribute/user-interaction-editing-designMode.html => testing/web-platform/tests/html/editing/editing-0/making-entire-documents-editable-the-designmode-idl-attribute/user-interaction-editing-designMode-xml.xml
extra : moz-landing-system : lando
* CreateFileW will return INVALID_HANDLE_VALUE (-1) on failure, not NULL (0).
* MapViewOfFile will map the entire section if the size is 0. No explicit size
is required.
* If SEC_IMAGE is specified, the mapped image size may be different from the
file size on the storage.
Differential Revision: https://phabricator.services.mozilla.com/D32563
--HG--
extra : moz-landing-system : lando
PresShell::EventHandler::HandleEventWithCurrentEventInfo is the only possible
place will do such handling; other places pass either a nullptr or a
non-MouseDown/Up event.
Differential Revision: https://phabricator.services.mozilla.com/D32431
--HG--
extra : moz-landing-system : lando
Since the purpose of mCurrentEventLoopDepth is to be ordered in comparison with
mNestedEventLoopDepth, it's a bit deceptive to give it a value that would appear
to be less than any reasonable depth but is, because the variables in question
are unsigned, actually greater than any reasonable depth. Using
mozilla::MaxValue<uint32_t>::value is clearer.
Differential Revision: https://phabricator.services.mozilla.com/D32198
--HG--
extra : moz-landing-system : lando
PrioritizedEventQueue's template is always EventQueue, so the template
argument is rather useless.
Trying to keep the patch minimal, so CreateMainThread for example is still
a bit weird.
Differential Revision: https://phabricator.services.mozilla.com/D31871
--HG--
extra : moz-landing-system : lando
This removes the XRE_TakeMinidumpForChild() which does not need to be
exposed anymore in the XUL API as well as
IToplevelProtocol::TakeMinidump() which was simply unused.
Differential Revision: https://phabricator.services.mozilla.com/D31062
--HG--
extra : moz-landing-system : lando
XPIDL has the requirement that [scriptable] interfaces with [notxpcom]
methods or attributes are [builtinclass]. Currently, if you don't
explicitly mark something builtinclass when it should be, then the
XPIDL compiler will just silently treat it like builtinclass. This
means that you can cause the JS implementation of an XPCOM to start
failing without any warning by marking a method notxpcom.
This patch instead makes it an error. A prior patch fixed the existing
instances in the tree that relied on the implicit behavior.
I also added a test that we reject such classes missing builtinclass
at compile time, as well as classes that inherit from builtinclass
interfaces without themselves being builtinclass. I left behind a part
of the runtime test for this behavior, but now this test just ensures
that you can't implement a [builtinclass] interface in JS.
Differential Revision: https://phabricator.services.mozilla.com/D30984
--HG--
extra : moz-landing-system : lando
If an XPIDL interface has a method or attribute that is [notxpcom],
then it is implicitly treated as [builtinclass], even if it is not
marked as such. For clarity, this patch goes through and marks every
place that relies on this behavior (aside from some test code).
Differential Revision: https://phabricator.services.mozilla.com/D30714
--HG--
extra : moz-landing-system : lando
We never emit an XPT for an interface that is not scriptable, so this
flag is never used.
Differential Revision: https://phabricator.services.mozilla.com/D30529
--HG--
extra : moz-landing-system : lando
With changes from bug 1548555, some of the gtests previously disabled on Android
can be re-enabled.
Differential Revision: https://phabricator.services.mozilla.com/D30080
--HG--
extra : moz-landing-system : lando
Consumers that just care about this boolean state should use this instead of
getting the JSObject* directly.
Differential Revision: https://phabricator.services.mozilla.com/D29705
--HG--
extra : moz-landing-system : lando
This patch makes editors return new error code internally when clipboard event
is dispatched and canceled by script. This is for making each caller stop
handling the edit action. However, it's not actual failure. Therefore, making
public methods return `NS_SUCCESS_DOM_NO_OPERATION` instead via
`EditorBase::ToGenericNSResult()`.
Differential Revision: https://phabricator.services.mozilla.com/D28935
--HG--
extra : moz-landing-system : lando
There's no good reason why we should let unnamed threads through this interface.
Differential Revision: https://phabricator.services.mozilla.com/D29672
--HG--
extra : moz-landing-system : lando
Temporarily just sidestep the issue in bug 1546498 (crash with latest SDK
on startup in Windows 7) by just continuing to use the old method in
Windows 7. We saw no wins in telemetry for Windows 7 anyway, so we should
investigate why that is, and why we see a mysterious crash in the fallback
code, in a followup bug.
Differential Revision: https://phabricator.services.mozilla.com/D29239
--HG--
extra : moz-landing-system : lando
Temporarily just sidestep the issue in bug 1546498 (crash with latest SDK
on startup in Windows 7) by just continuing to use the old method in
Windows 7. We saw no wins in telemetry for Windows 7 anyway, so we should
investigate why that is, and why we see a mysterious crash in the fallback
code, in a followup bug.
Differential Revision: https://phabricator.services.mozilla.com/D29239
--HG--
extra : moz-landing-system : lando
Changes:
- added comments for tests being disabled
- disabled two additional tests in order to green the run
Differential Revision: https://phabricator.services.mozilla.com/D28085
--HG--
extra : moz-landing-system : lando
nsITabParent is exposed to frontend code and is generally used as a representation of a remote tab. We could just rename the interface to nsIBrowserParent and worry about it later, but I think it's better to rename the interface to nsIRemoteTab so that we can later work on splitting the interface away from the PBrowser protocol.
Note: Some frontend code refers to a TabParentId. This commit renames this to RemoteTabId. We need to figure out the purpose of TabId with fission.
Differential Revision: https://phabricator.services.mozilla.com/D28132
--HG--
rename : dom/interfaces/base/nsITabParent.idl => dom/interfaces/base/nsIRemoteTab.idl
extra : rebase_source : 9d8a1790a7bb10195ad063644d1a93d63b2afb72
Also, this checks for strings with nulls, which is nice (though I guess an
uncommon mistake).
Differential Revision: https://phabricator.services.mozilla.com/D28312
--HG--
extra : moz-landing-system : lando
Don't assume XPCOM_MEM_BLOAT_LOG is a filename. XPCOM_MEM_BLOAT_LOG and XPCOM_MEM_LEAK_LOG can be set to a filename or "1" or "2" for logging to stdout and stderr respectively.
Set the debug write directory for XPCOM_MEM_LEAK_LOG in the same way we already to for XPCOM_MEM_BLOAT_LOG.
Differential Revision: https://phabricator.services.mozilla.com/D27968
--HG--
extra : moz-landing-system : lando
- `Array.map` becomes `Array.from`
- Array copying via `Array.slice` becomes `Array.from`.
- `Array.forEach` that did not rely on closures becomes `for`-`of` loops.
- Anything else: `Array.X` becomes `Array.prototype.X`.
Complex cases:
dom/bindings/test/TestInterfaceJS.js and
dom/bindings/test/test_exception_options_from_jsimplemented.html
use `Array.indexOf` to generate an error with a specific error message.
Switched to `Array.prototype.forEach` to generate the same error.
js/src/jit-test/tests/basic/exception-column-number.js
In this test `Array.indexOf()` is used to generate an error. Since the
exact message doesn't matter, I switched to `Array.from()`.
Intentionally not changed:
editor/libeditor/tests/browserscope/lib/richtext/richtext/js/range.js
Did not modify because this is 3rd-party code and the code uses
feature detection as a fall back when Array generics are not used.
testing/talos/talos/tests/dromaeo/lib/mootools.js
Did not modify because mootools adds the `Array.slice` method to the
`Array` object.
Not changed because they check the implementation of Array generics:
js/src/jit-test/tests/basic/arrayNatives.js
js/src/jit-test/tests/basic/bug563243.js
js/src/jit-test/tests/basic/bug618853.js
js/src/jit-test/tests/basic/bug830967.js
js/src/jit-test/tests/jaeger/recompile/bug656753.js
js/src/jit-test/tests/self-hosting/alternate-static-and-instance-array-extras.js
js/src/tests/non262/Array/generics.js
js/src/tests/non262/Array/regress-415540.js
js/src/tests/non262/extensions/regress-355497.js
js/src/tests/non262/extensions/typedarray-set-neutering.js
Depends on D27802
Differential Revision: https://phabricator.services.mozilla.com/D27803
--HG--
extra : moz-landing-system : lando
On startup we record the size and modified time of the profile lists. If
changed we refuse to flush any new changes to disk. Also adds a getter to check
if they've changed so the UI can do something sensible.
All attempts to flush are now checked for success. In some cases in early
startup the failure mode isn't great, we just quit startup. The assumption
though is that it's extremely unlikely that the files will have changed on disk
in the time between when they are read and when profile selection occurs, likely
less than a second later.
The profile reset flow is changed to only delete the old profile and flush once
all the migration has completed, so if something fails the user gets back to
their old profile.
In testing I ended up having to fix bug 1522584 so background file deletions on
a background thread are safer.
I haven't implemented any UI tests right now since making modifications to the
profiles means modifying the actual user's profiles which I'm not keen to do.
See bug 1539868.
Differential Revision: https://phabricator.services.mozilla.com/D25278
--HG--
extra : moz-landing-system : lando
On startup we record the size and modified time of the profile lists. If
changed we refuse to flush any new changes to disk. Also adds a getter to check
if they've changed so the UI can do something sensible.
All attempts to flush are now checked for success. In some cases in early
startup the failure mode isn't great, we just quit startup. The assumption
though is that it's extremely unlikely that the files will have changed on disk
in the time between when they are read and when profile selection occurs, likely
less than a second later.
The profile reset flow is changed to only delete the old profile and flush once
all the migration has completed, so if something fails the user gets back to
their old profile.
In testing I ended up having to fix bug 1522584 so background file deletions on
a background thread are safer.
I haven't implemented any UI tests right now since making modifications to the
profiles means modifying the actual user's profiles which I'm not keen to do.
See bug 1539868.
Differential Revision: https://phabricator.services.mozilla.com/D25278
--HG--
extra : moz-landing-system : lando
This patch introduces an asynchronous XPCOM interface for the bits client added in Bug 1523417
Differential Revision: https://phabricator.services.mozilla.com/D25161
--HG--
extra : moz-landing-system : lando
I missed this intermittent when enabling Android gtests in bug 1318091. Disable
the failing test on Android only, to green up Android gtest.
Differential Revision: https://phabricator.services.mozilla.com/D27535
--HG--
extra : moz-landing-system : lando
Our old approach was reading this into a region of unexecutable memory,
meaning when we actually loaded the library it needed to be loaded into
executable memory. This fixes that. I suspect that any gains we were
seeing previously were due to hardware effects.
Differential Revision: https://phabricator.services.mozilla.com/D26018
--HG--
extra : moz-landing-system : lando
There shouldn't be any need to do this for content processes as
the DLL should already be in the system file cache.
Differential Revision: https://phabricator.services.mozilla.com/D26017
--HG--
extra : moz-landing-system : lando
This is just to make it simpler to use PrefetchVirtualMemory in subsequent patches.
Differential Revision: https://phabricator.services.mozilla.com/D26016
--HG--
extra : moz-landing-system : lando
Our old approach was reading this into a region of unexecutable memory,
meaning when we actually loaded the library it needed to be loaded into
executable memory. This fixes that. I suspect that any gains we were
seeing previously were due to hardware effects.
Differential Revision: https://phabricator.services.mozilla.com/D26018
--HG--
extra : moz-landing-system : lando
There shouldn't be any need to do this for content processes as
the DLL should already be in the system file cache.
Differential Revision: https://phabricator.services.mozilla.com/D26017
--HG--
extra : moz-landing-system : lando
This is just to make it simpler to use PrefetchVirtualMemory in subsequent patches.
Differential Revision: https://phabricator.services.mozilla.com/D26016
--HG--
extra : moz-landing-system : lando
(more a feedback request than review request at this stage)
Adding a new attribute to the panel was the easiest way I could find to make this work without too much plumbing
However I don't know how to check that the attribute comes from a chrome privileged script. I tried using PresContext()->IsChrome() but this is also false in our situation.
Would you prefer another approach? Otherwise what kind of test would you write for this kind of feature?
Differential Revision: https://phabricator.services.mozilla.com/D26211
--HG--
extra : moz-landing-system : lando
Because not all static components are using the static registration yet,
we can end up in situations where a same component is registered
multiple times, which can have some unexpected consequences.
Interestingly enough, this change revealed that we did have static
registration in place for components that were kept under the old system
after bug 1478124 and bug 1524687.
There are also possibly some non-obvious things that can happen while
migrating the remaining components, like what happened to me while I
worked on @mozilla.org/widget/components;1 (see bug 1542214 comment 0).
Differential Revision: https://phabricator.services.mozilla.com/D26698
--HG--
extra : moz-landing-system : lando
Bug 1478124 and bug 1524687 converted many things to static xpcom
component registration, but somehow left the corresponding C++
initialization.
Differential Revision: https://phabricator.services.mozilla.com/D26697
--HG--
extra : moz-landing-system : lando
Originally, RDD reused the GPU process selector since they were
using all the same services, and it reduced the number of places
that had to be touched. Now that RDD needs pref handling, it
needs its own process selector to avoid GPU inheriting pref
handling.
Differential Revision: https://phabricator.services.mozilla.com/D26566
--HG--
extra : moz-landing-system : lando
Whenever chrome JS code leaks, we leak the dynamic atom "[System
Principal]". This causes an assertion, which hangs the browser in
stack walking code for multiple minutes on OSX. As a bandaid, make
this atom static so it won't leak.
My first instinct is that it would make sense to use this new atom
directly in SystemPrincipal, but atoms are represented internally as a
kind of nsAString, but principal code uses nsACStrings, so you end up
with an extra conversion from 16-bit to 8-bit.
This atom is also going to be present in any process running chrome
JS, so this will save a little bit of memory.
Differential Revision: https://phabricator.services.mozilla.com/D26590
--HG--
extra : moz-landing-system : lando
Before bug 938437, we had a rather large and error-prone
nsStaticXULComponents.cpp used to register all modules. That was
replaced with clever use of the linker, which allowed to avoid the mess
that maintaining that file was.
Fast forward to now, where after bug 1524687 and other work that
preceded it, we have a much smaller number of remaining static xpcom
components, registered via this linker hack, and don't expect to add
any new ones. The list should eventually go down to zero.
Within that context, it seems to be the right time to get rid of the
magic, and with it the problems it causes on its own.
Some of those components could probably be trivially be converted to
static registration via .conf files, but I didn't want to deal with the
possible need to increase the number of dummy modules in XPCOMInit.cpp.
They can still be converted as a followup.
Differential Revision: https://phabricator.services.mozilla.com/D26076
--HG--
extra : moz-landing-system : lando
The binary path type of a particular content process is useful information
outside of IPC. Given that `XRE_EnableSameExecutableForContentProc` already
exists, and given that the binary path type is closely related to
`GeckoProcessType`, I've added a new function, `XRE_GetContentProcBinPathType`.
The mapping of process type to binary type has been moved to the
`GeckoProcessTypes` definitions.
This patch also modifies `ipc::GeckoChildProcessHost` to call into the new
function.
Differential Revision: https://phabricator.services.mozilla.com/D25816
--HG--
extra : histedit_source : acdfd2357fd06551dff5286c6b7c56bd92dd347b
Disable gtests observed to fail on Android. Some of these are simple build
failures and failures due to file permissions or paths, while other failures
are more obscure.
Once Android gtests are running on mozilla-central, I will file follow-up
bugs inviting teams to investigate the failures and re-enable Android gtests
that are important to them.
Differential Revision: https://phabricator.services.mozilla.com/D26606
--HG--
extra : moz-landing-system : lando
The binary path type of a particular content process is useful information
outside of IPC. Given that `XRE_EnableSameExecutableForContentProc` already
exists, and given that the binary path type is closely related to
`GeckoProcessType`, I've added a new function, `XRE_GetContentProcBinPathType`.
The mapping of process type to binary type has been moved to the
`GeckoProcessTypes` definitions.
This patch also modifies `ipc::GeckoChildProcessHost` to call into the new
function.
Differential Revision: https://phabricator.services.mozilla.com/D25816
--HG--
extra : moz-landing-system : lando
This is based on the `c_str` macro in `js/rust/src/heap.rs`, but
returns a `NulTerminatedCStr` type that can be cast to a pointer.
This commit also changes `ThreadPtrHolder::new` to take a
`NulTerminatedCStr`, and removes an unnecessary `RefPtr` reference in
`is_current_thread`.
Differential Revision: https://phabricator.services.mozilla.com/D26429
--HG--
extra : moz-landing-system : lando
If the environment variable MOZ_GC_LOG_SIZE is set, then GC logs will
include some extra data that indicates how much memory the GC thing
uses, including extra data hanging off of it. This can be used
calculate finer grained information about the memory usage of scripts.
Differential Revision: https://phabricator.services.mozilla.com/D25882
--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
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
Oana Pop Rus
Tarek Ziadé
Gurzau Raul
Emilio Cobos Álvarez
Gabriele Svelto
Olli Pettay
Masatoshi Kimura
Haik Aftandilian
Dorel Luca
Bogdan Tara
Brendan Dahl
Andrea Marchesini
Andreea Pavel
Gerald Squelart
Ciure Andrei
Boris Zbarsky
Mirko Brodesser
Gijs Kruitbosch
Valentin Gosu
Matt Woodrow
Daniel Varga
Csoregi Natalia
Nika Layzell
shindli
Mike Hommey
Dave Townsend
Brian Hackett
Nicklas Boman
Jonathan Kingston
Nathan Froyd
Honza Bambas
Ehsan Akhgari
Edgar Chen
Jonathan Kew
Aaron Klotz
Jean-Yves Avenard
Sylvestre Ledru
Randell Jesup
arthur.iakab
Kartikaya Gupta
Jim Blandy
Cosmin Sabou
Dzmitry Malyshau
Sean Feng
Bastien Orivel
ffxbld
Brian Birtles
Andrew McCreight
Brindusan Cristian
Geoff Brown
Frederik Braun
Masayuki Nakano
Mike Conley
Doug Thayer
Noemi Erli
Zibi Braniecki
Edwin Gao
Ryan Hunt
Myk Melez
Coroiu Cristina
Byron Campen [:bwc]
Razvan Maries
Rob Wu
Ian Moody
Kirk Steuber
Henri Sivonen
Cameron McCormack
Martin Stransky
Julian Descottes
Michael Froman
Lina Cambridge
Jeff Walden
Narcis Beleuzu
Randall E. Barker
Petr Sumbera
Daosheng Mu
Andrew Osmond
Eden Chuang
Jeff Gilbert
Philip Chimento
Mark Banner
Mats Palmgren