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
Mirko Brodesser
Nicklas Boman
Jonathan Kingston
Nathan Froyd
Honza Bambas
Gijs Kruitbosch
Ehsan Akhgari
Masatoshi Kimura
Edgar Chen
Dave Townsend
Jonathan Kew
Aaron Klotz
Jean-Yves Avenard
Sylvestre Ledru
Gurzau Raul
Randell Jesup
Gabriele Svelto
arthur.iakab
Kartikaya Gupta
Jim Blandy
Cosmin Sabou
Dzmitry Malyshau
Olli Pettay
Sean Feng
Bastien Orivel
ffxbld
Brian Birtles
Boris Zbarsky
Emilio Cobos Álvarez
Andrew McCreight
Brindusan Cristian