Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : 59e4a6ced7d14d2a01c0b79e944078ea84cae523
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : a8840bd26f4b01b756ffa72345ababb625048550
Based on similar functionality for ICU. Define a GMPReporter class and
use its methods for libgmp allocation.
--HG--
extra : rebase_source : 4b536f8a331146109f1cbecf7246f5d4063ec457
Whatever compiler bugs required this destructor to be public have
either long since been fixed, or the compilers themselves have become
obsolete. Plus we get to fix a wrong comment and make another class
final in the process.
The schema handling for this is currently a bit ugly, for the sake of
simplifying uplift. In the figure, we should find a way to change the schema
pattern matching based on whether or not the extension is privileged.
MozReview-Commit-ID: CU9WR2Ika6k
--HG--
extra : rebase_source : 28e1c43cf0f0efc01b40757e4e65c4ac5d882258
This patch defines NS_ERROR_EDITOR_DESTROYED error code as an editor module
specific error code.
And creates TextEditRules::CanHandleEditAction() to check if the instance
can keep handling edit action.
MozReview-Commit-ID: 4qECwNBO0yz
--HG--
extra : rebase_source : a925a9b6840d4d06e2792b9fe276e062288b0806
Using concrete class types with static IIDs in QueryInterface methods is a
pretty common pattern which isn't supported by any existing helper macros.
That's lead to separate ad-hoc implementations, with varying degrees of
dodginess, being scattered around the tree.
This patch adds a helper macro with a canonical (and safe) implementation, and
updates existing ad-hoc users to use it.
MozReview-Commit-ID: HaTGF7MN5Cv
--HG--
extra : rebase_source : ace930129d85960d22bc3048ca3bb19bbbd4a63e
extra : histedit_source : 03a87f746d957789d41381e4e1bfcc4fd7eebaf2%2C9c5bae9feeeef7721105db67be0f83e0ded66bb7
All of our GetDirectoryEntries implementations return a
nsIDirectoryEnumerator, and a lot of relies on this, and explicitly QIs to it.
That gets a bit ugly, and in JS code, a bit expensive. We should just return a
directory enumerator directly if that's part of the API contract.
MozReview-Commit-ID: IUeEB1Ih1Wu
--HG--
extra : rebase_source : 6fffb2d4b0f83db1fd270423a195379acef0dfe4
Any more specific work that is happening in these methods will have its own
specific category labeling in that specific code. The instances touched in this
patch are more on the outside and don't really know what kind of code is going
to be running inside.
MozReview-Commit-ID: 47NO1DZzkdH
--HG--
extra : rebase_source : 344c380ddaaf42a1fd820a26b762c61ee9e2d524
They're very similar as far as most users of the profiler are concerned, I'd
say, and I don't believe it's worth giving them two different colors in the
activity graphs.
MozReview-Commit-ID: HTqjp56naL3
--HG--
extra : rebase_source : cf8d64bc3e76ed9bb07100081aebfc404845b8bc
Any more specific work that is happening in these methods will have its own
specific category labeling in that specific code. The instances touched in this
patch are more on the outside and don't really know what kind of code is going
to be running inside.
MozReview-Commit-ID: 47NO1DZzkdH
--HG--
extra : rebase_source : f807c14bf6a592e0c651e15b63d1e7d63e4b0159
They're very similar as far as most users of the profiler are concerned, I'd
say, and I don't believe it's worth giving them two different colors in the
activity graphs.
MozReview-Commit-ID: HTqjp56naL3
--HG--
extra : rebase_source : ed1dc54efd143ad64bc21cfc39853ae90477cc9d
Currently XPCVariant has some code for working with arrays of a series of basic
types. I want to unify and simplify code which works with nsXPTTypes to always
take the topmost level type (rather than passing in an array element type when
working with an array).
This is pretty easy for most of XPConnect, but XPCVariant occasionally needs to
perform calls on made-up array types, which isn't compatible with the current
implementation. Fortunately, it only needs a very small set of array types. This
patch adds a set of simple types (mostly the arithmetic types and
TD_INTERFACE_IS_TYPE for interfaces) to the extra types array unconditionally
with a known index, for XPCVariant.
An other option I was considering was to consider the value `0xff` in the data
byte on nsXPTType to be a flag which indicates that the array element type is
actually the type immediately following the current nsXPTType object in memory,
but that was incompatible with many of the existing nsXPTType consumers which
copy the nsXPTType objects around (e.g. onto the stack), rather than always
using them by reference, so I decided it was not a good approach to take.
In XPConnect, native values are passed around within nsXPTCMiniVariant objects.
an [nsXPTCMiniVariant] contains 64-bits of data in a union type.
nsXPTCMiniVariant values are created by the platform-specific glue code and
passed into XPConnect proper when calling from C++ into JS.
When calling from JS into C++, we instead create nsXPTCVariant objects and pass
them into the glue code. These objects have extra information in addition to the
nsXPTCMiniVariant: namely they also have a `type` field with the type stored in
the variant, space for flags, and a `ptr` field which is passed over IPC instead
of the inner nsXPTCMiniVariant when a flag (`PTR_IS_DATA`) is set.
The JSValue type in XPConnect is always passed as a pointer to a JSValue object,
both for in parameters and out parameters. This is handled by making the JSValue
type be unconditionally flagged as [`IsIndirect()`] This flag is also used for
all types of outparameters.
When the `IsIndirect()` flag is set, it means that the actual data is stored in
the nsXPTCVariant's val field, and it sets the flag to tell the glue code to
instead pass the `ptr` field (which is always pointing to the `val` field for
[legacy reasons]) into the C++ code.
In contrast "dipper" is a different and super weird flag. Currently only the
string class types (nsACString & nsAString) are marked as "dipper". A "dipper"
type is always passed as an "in" type (and thus always passed "directly"), even
when it's actually an out parameter.
XPConnect treats these types as though they are pointer types (nsAString*). This
means that there is no space in the nsXPTCVariant to store the actual nsAString
types when passing from JS into C++, so these values have to be allocated by a
different mechanism (in the current code, there is a size 2 buffer for each
string type in the context and once that buffer is exceeded, we heap allocate
the nsString values).
In effect, the current state looks something like this:
+------------+---------------------+---------------------+
| type | out (xpt/native) | in (xpt/native) |
+------------+---------------------+---------------------+
| TD_INT32 | indirect (int32_t*) | direct (int32_t) |
+------------+---------------------+---------------------+
| TD_JSVAL | indirect (JSValue*) | indirect (JSValue*) |
+------------+---------------------+---------------------+
| TD_ASTRING | direct (nsAString*) | direct (nsAString*) |
+------------+---------------------+---------------------+
This patch ensures there is enough space in the nsXPTCVariant to fit the
nsString value, and switches string class types to being unconditionally
indirect instead of using the dipper system. This allows us to delete a ton of
dipper-specific code, and unify the indirect and string class codepaths.
This only affects the size of nsXPTCVariant objects, and does not affect
nsXPTCMiniVariant objects. nsXPTCVariant objects are never allocated by the
platform-specific binding code, rather, they are allocated in an AutoTArray on
the stack as part of the CallMethodHelper object.
The size increase is a total of 1 word, so 4 bytes in 32-bit builds, and 8 bytes
in 64-bit builds, which is ignorable for stack allocated objects.
[nsXPTCMiniVariant]: https://searchfox.org/mozilla-central/rev/eb6c5214a63e20a3fff455e92c876287a8d2e188/xpcom/reflect/xptcall/xptcall.h#20-47
[`IsIndirect()`]: https://searchfox.org/mozilla-central/rev/c0d81882c7941c4ff13a50603e37095cdab0d1ea/xpcom/reflect/xptinfo/xptinfo.h#371
[legacy reasons]: https://searchfox.org/mozilla-central/rev/eb6c5214a63e20a3fff455e92c876287a8d2e188/xpcom/reflect/xptcall/xptcall.h#66-79
We are going to want to include some "gecko internal" types in more places in
the codebase, and we have unused includes of some of these headers in non-libxul
files.
This patch just cleans up these unnecssary includes.
It used to be that in XPConnect there were many different pieces of code for
each place where we may need to clean up some untyped values based on their
nsXPTType information. This was a mess, and meant that every time you needed to
add a new data type you'd have to find every one of these places and add support
for your new type to them.
In fact, this was bad enough that it appears that I missed some places when
adding my webidl support! Which means that in some edge cases we may clean up
one of these values incorrectly D:!
This patch adds a new unified method which performs the cleanup by looking at a
nsXPTType object. The idea is that this function takes a void* which is actually
a T* where T is a value of the nsXPTType parmaeter. It clears the value behind
the pointer to a valid state such that free-ing the memory would not cause any
leaks. e.g. it free(...)s owned pointers and sets the pointer to `nullptr`, and
truncates nsA[C]String values such that they reference the static empty string.
I also modify every one of these custom cleanup codepaths to instead call into
this unified cleanup method.
This also involved some simplification of helper methods in order to make the
implementation cleaner.
This type is fairly simple on the idl parsing side of things. I handle it in the
same way that special types such as ns[C]String, nsid, and jsval are handled, by
using a special native type.
The logic for converting the value between C++ and JS follows the existing logic
from the nsISupports <=> JS Promise conversions.
When memory-pressure events were first used in an e10s environment it was
to implement memory minimization from about:memory. However when low memory
detection was first introduced in Firefox OS an issue arised with this scheme:
every process was using a kernel-based low-latency mechanism to detect low
memory scenarios and send memory-pressure events; but the main process events
were also being forwarded to all child processes causing listeners to be
triggered twice. Because of this -no-forward events were introduced and used.
Currently however low-memory is detected via polling, so there will always be
a significant delay between the beginning of the low-memory scenario and its
detection. Because of this there is no value in having content processes poll
on their own and it's best to have only the main process do it and then
forward the memory-pressure events to all child processes.
MozReview-Commit-ID: AMQOsEgECme
--HG--
extra : rebase_source : 1b408b31dd27940981407f50f2e5f07e354b16d7
This patch introduces a new polling mechanism to detect low-memory scenarios.
The timer fires at a relatively slow pace and stops whenever the user stops
interacting with Firefox to avoid consuming power needlessly. The polling rate
is up to 3 orders of magnitude slower than the current tracker and is
throttled when memory is running low. It also doesn't suffer from data races
that were possible with existing tracker.
Contrary to the old available memory tracker which relied on a
Windows-specific mechanism, this one could be made to work on other platforms
too. The current implementation only supports Windows 64-bit builds though.
MozReview-Commit-ID: CFHuTDqjPbL
--HG--
extra : rebase_source : 92d1f801cc680f9fde8ecfa46c570e3c562a3d01
"alloc-failure" is completely unused apart from the description text in nsI-
Memory.idl (and has been since before Firefox 17), while "lowering-priority" is
still being checked for in the PuppetWidget, but otherwise unused as well since
the feature using it was decommissioned in bug 1234176.
Since we're touching the PuppetWidget code anyway, we take the opportunity to
add a check for "low-memory-ongoing" instead, since similar as to how things
used to be with "lowering-priority", we want to drop the LayerManager's cached
resources only when receiving a real full memory-pressure event, but not for
subsequent ongoing notifications.
MozReview-Commit-ID: HL03SOU8axe
--HG--
extra : rebase_source : c988769df36d8d77f4770c71d5c5e0d75c3b99af
For some reason, the CC spends a lot of time tracing jsids on
ObjectGroups when an addon is installed. This patch avoids that by
adding a canSkipJsids flag to JSTracer, and using it in
ObjectGroup::traceChildren. If this is true, then the tracer is free
to not report every jsid. This flag is set to true for the two CC
tracers.
MozReview-Commit-ID: CWFqQEr0SxV
--HG--
extra : rebase_source : cc31c22717f8990166454db191e0d40c145e09f0
These were found using some ugly text searches, so it's possible some unused
atoms remain. In the future, we should enforce removing unused atoms using
static analysis. Or just generate the static atoms table based on string atom
names in our code.
This patch leaves unused RDF atoms in place, since those are being dealt with
in another bug.
MozReview-Commit-ID: 1KpH9KsHzQy
--HG--
extra : rebase_source : 8138faa2b16e847da31861abae2bbc1c7bac4e02
The JS engine has changed the APIs that cooperative scheduling relies
on into immediate crashes. Some users seem to set the prefs, and then
we get a lot of crashes on Nightly. This removes the top-level pref to
save them some grief.
I continue to pass the pref as false to the child process to avoid
weirdness if we somehow we get this far when the parent and child have
different versions.
MozReview-Commit-ID: 3o3yV2efx2r
--HG--
extra : rebase_source : 398c4d77ce3f78f3814ac97882b4a5e3190c44f7
For Fennec on Android, if we haven't received memory pressure notifications from
the OS for a certain amount of time (in the order of ~15 mins), we assume that
we're no longer under memory pressure. In order to turn the bfcache back on when
that happens, we now want to be able to forward this fact to Gecko as well.
Unfortunately, the way memory pressure is tracked using an atomic variable
doesn't easily allow to fully extend the existing priority rules between "new"
and "ongoing" to include a new "stopping of memory pressure" event. Since we're
not using Dispatch*Eventual*MemoryPressure on Android and therefore the queuing
priority behaviour isn't actually relevant for us, we just ignore that and only
enforce that a pending "new" memory pressure event takes priority over a "stop"
event.
MozReview-Commit-ID: 90C9KogUyvf
--HG--
extra : rebase_source : 4e71a31433557d8d486f941953717a88d5d87e7d
Move tracking of persistent window state into nsXULWindow. Also, move
special handling of the width/height of the window into nsXULWindow.
MozReview-Commit-ID: LOmHGyYeNSU
--HG--
extra : rebase_source : bcea16eb6209ff789948644a64968a7325cea4ef
Also fixes existing code which fails the rule.
MozReview-Commit-ID: CkLFgsspGMU
--HG--
extra : rebase_source : 86a43837659aa2ad83a87eab53b7aa8d39ccf55b
Use fatal MOZ_ASSERT or non-fatal NS_ASSERTION instead.
MozReview-Commit-ID: 1QAsgoWpXDn
--HG--
extra : source : 9ca972b6b3e7d3b576e20a0bf412df51d82aad9f
extra : intermediate-source : a909a9d7bc9a53095e963a4bea45f4fc4aa85b72
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
Honza Bambas
Bharat Raghunathan
Doug Thayer
Steve Fink
Panos Astithas
Gurzau Raul
Boris Zbarsky
Gabriele Svelto
Jan de Mooij
Dorel Luca
Bogdan Tara
Kristen Wright
Robin Templeton
Nathan Froyd
Brindusan Cristian
Andreea Pavel
Andrea Marchesini
Kris Maglione
Masayuki Nakano
Mike Hommey
Emilio Cobos Álvarez
Noemi Erli
Randell Jesup
Coroiu Cristina
Adam Gashlin
Csoregi Natalia
Markus Stange
Cosmin Sabou
Raymond FOrbes
Marco Bonardo
Nika Layzell
Peter Van der Beken
Jan Henning
Andrew McCreight
Brendan Dahl
Chris Peterson
Stephen A Pohl
arthur.iakab
sotaro