This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13073
--HG--
extra : moz-landing-system : lando
This sends a sync IPC message to the compositor after each crashtest, to
ensure that any stuff inflight in the compositor settles down. In
particular this should round-trip through all of the relevant compositor
threads (i.e. for WebRender it should ensure the scene builder, render
backend, and renderer threads all get flushed).
Differential Revision: https://phabricator.services.mozilla.com/D13033
--HG--
extra : moz-landing-system : lando
We were dipatching the "connect" request manually, whereas we should be using
protocol.js specifications. It also help getting rid of another use of "form"
instead of "front"/activeTab in Target class.
MozReview-Commit-ID: IOH4mDprAVL
Depends on D12577
Differential Revision: https://phabricator.services.mozilla.com/D12578
--HG--
extra : moz-landing-system : lando
I did a dedicated patch for converting both about:debuggings as it is slightly more
complex as we have to tweak redux data, wrappers, mocks.
This patch also convert a manual "reload" request being done by about:debugging
and instead use protocol.js front to do it.
Also, I moved isLegacyTemporaryExtension to the front as it depends on accessing the form
and it should be better to keep form processing to the fronts, if possible.
MozReview-Commit-ID: 16qZkuCBp9b
Depends on D12576
Differential Revision: https://phabricator.services.mozilla.com/D12577
--HG--
extra : moz-landing-system : lando
Adapt to the new returned value of listAddons
and also always call it from RootFront instead of DebuggerClient.
Fix the spec in order to expose reload on the front (it was a miss from a previous patch).
MozReview-Commit-ID: AQ5EOQEqnxX
Depends on D12575
Differential Revision: https://phabricator.services.mozilla.com/D12576
--HG--
extra : moz-landing-system : lando
This is a straight backout of (in that order) bug 1505468, bug 1503664, bug
1501479, bug 1499150, bug 1496805, and the second part of bug 1493849. The
first part of bug 1493849 was a backout of earlier instrumentation, and that
should stay.
At this point we know we're hitting OOM inside the JS engine while trying to
define properties on Document.prototype, so all this MOZ_CRASH instrumentation
is no longer needed.
In particular, in nsCharClipDisplayItem::IsSelected() we know that
the frame must be a nsTextFrame (or nsContinuingTextFrame) which
means nsTextFrame::IsFrameSelected() can be called directly now.
When shutting down a content process, we call `Close` on the
`IToplevelProtocol`. This causes the MessageChannel to be `Close`-ed,
which in turn sends a `GOODBYE_MESSAGE`:
https://searchfox.org/mozilla-central/rev/876022232b15425bb9efde189caf747823b39567/ipc/glue/MessageChannel.cpp#2852
This message is intercepted on the I/O thread in the content process,
before any code is informed in content, and used to set the
`mChannelState` property to `ChannelClosing`:
https://searchfox.org/mozilla-central/rev/876022232b15425bb9efde189caf747823b39567/ipc/glue/MessageChannel.cpp#1176
Once this state has been set, which is performed as soon as the
message is received, whether or not other messages have been processed
yet, no messages can be sent back to the parent process. This is
usually what causes the 'Too late to send/recv' message spam in the
console, as we're still trying to send messages at this time.
Usually this is fine - the message send fails, but we gracefully
recover, and the process begins shutting down like normal.
Unfortunately, child actor constructors currently have code
automatically generated in them which causes a process crash if the
send fails. As it's impossible for the main thread to know that the
channel has been closed ahead of time (due to this happening
out-of-band), we can then cause random content process crashes
during shutdown due to actor construction.
Unfortunately, we can't just destroy the actor, as our caller may
(and often do) depend on the actor reference they gave us still being valid
after calling Send*Constructor. Fortunately, if a message send failed, it means
we're in the process of being shut down.
This patch handles this by ignoring ctor send errors, and treating them like
messages which successfully were queued to send, but got lost due to the other
side hanging up. The actor will be gracefully destroyed in DestroySubtree when
its manager is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D12695
Previously there were many different inconsistent implementations of this
variable across many different actors. This adds a unified implementation of
this variable inside of IProtocol.
Differential Revision: https://phabricator.services.mozilla.com/D12956
Previously this actor would call `Send__delete__` in its destructor, meaning
that the lifetime of the actor is a bit hard to follow. This changes the actor
to instead use a separate object for XPCOM, and use refcounting universally.
This should also help with the transition to universally refcounted actors.
Differential Revision: https://phabricator.services.mozilla.com/D12955
This will be useful as both an ID for PWindowGlobal, as well as a mechanism for
taking advantage of already synchronized information. As an example, LoadInfo
objects contain the inner window IDs of the window requesting the load, which
can now be used to obtain a reference to the corresponding WindowGlobalParent
in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D9396
This should make BrowsingContext more usable by making it much easier to obtain
for a given frame or browser. BrowsingContext and nsFrameLoader should have
the same lifetime.
Differential Revision: https://phabricator.services.mozilla.com/D9395
This serves 2 purposes:
1. Provides an object corresponding to an inner window which Chrome JS can hold onto.
2. Provides the object to JS which Chrome JS per-window actors will be attached to.
3. Provides useful information to Chrome JS in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D9394
This allows getting the set of all window globals for a given browsing context.
This is less useful at the moment as the active window global is not exposed as
such. That will be added as a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D9393
By default, windows.h exposes a large number of problematic define statements
which are UpperCamelCase, such as a define from `CreateWindow` to
`CreateWindow{A,W}`.
As many of these names are generic (e.g. CreateFile, CreateWindow), they can
mess up Gecko code that may legitimately have its own methods with the same
names.
The header also defines some traditional SCREAMING_SNAKE_CASE defines which
can mess up our code by conflicting with local values.
This patch adds a simple code generator which generates wrappers for these
defines, and uses them to wrap the windows.h wrapper using the `stl_wrappers`
mechanism, allowing us to use windows.h in more places.
Differential Revision: https://phabricator.services.mozilla.com/D10932
This actor can be used for communicating with individual frames, without
depending on walking the tree in the content process.
This is not yet complete. No tests have been written for it, the
WindowGlobalParent objects need to be exposed to chrome JS, and a form of JS
actors should be installed under them.
In addition, BrowsingContextChrome objects should be updated to allow access to
the current WindowGlobalParent in that context.
Differential Revision: https://phabricator.services.mozilla.com/D4623
This will be useful as a basis for asynchronous actors which would like to exist
both when crossing the process boundary (managed by PContent), and when
displaying an in-process window.
Differential Revision: https://phabricator.services.mozilla.com/D4622
To create a more generic interface for interacting both within the main thread
of the parent process and between the parent and child processes, it would be
nice to support IPDL actors within the main thread of the parent process. This
requires the underlying MessageChannel actor to support intra-thread links.
This change adds support for intra-thread links to the underlying MessageChannel
object using ThreadLink, and an extra boolean flag.
Differential Revision: https://phabricator.services.mozilla.com/D4620
Previously the omnibox keyword would not allow trailing slashes, such as go/
Chrome allows this keyword, and Firefox should allow this too.
Differential Revision: https://phabricator.services.mozilla.com/D12242
--HG--
extra : moz-landing-system : lando
Timothy Guan-tin Chien
Sylvestre Ledru
Ehsan Akhgari
Henrik Skupin
Kartikaya Gupta
WR Updater Bot
Alexandre Poirot
Rob Thijssen
Brian Hackett
Boris Zbarsky
Mats Palmgren
Wes Kocher
Erica Wright
Raphael Pierzina
Ekanan Ketunuti
arthur.iakab
Jeff Gilbert
Nika Layzell
hawaiianchimp
Tom Prince
Mike Conley
alwu
Matthew Gaudet
Emilio Cobos Álvarez