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
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
Boris Zbarsky
Gabriele Svelto
Jan de Mooij
Dorel Luca
Doug Thayer
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
Cosmin Sabou
Raymond FOrbes
Marco Bonardo
Nika Layzell