RDM frames with their custom message manager hadn't exposed a value for
`processMessageManager`. This was just a oversight.
By adding this value, we get a working Browser Content Toolbox for RDM tabs.
MozReview-Commit-ID: 95QskEMKgZK
--HG--
extra : rebase_source : 5259800f64afe55ee5bca29492f6f33efcfd458c
This will resolve several intermittments that were occuring because we would
occasionally get unlucky and have a jitter midpoint of 0, making an unstarted
AudioContext report a CurrentTime of 100us (or 1ms - whatever our clamp value
was.)
MozReview-Commit-ID: 45zXLbB93wP
--HG--
extra : rebase_source : 23ea5964dc49543c2b4ca45890c4c08456e75c73
Clean up the Settings JS modules a little. Don't keep extra state
variables if we don't have to.
Set displayMode inside the proper frame script rather than through a
data URI. Because we never unregister frame scripts, the data URIs can
start accumulating if display mode is changed several times.
MozReview-Commit-ID: G8DtH6U8mVh
--HG--
extra : rebase_source : 901454858995bf5ca5a9b20478ad754ffdabb5c5
Set the browse remote attribute in onInitBrowser so we only set it once
and don't have to remove and re-add the browser to the window.
MozReview-Commit-ID: LJGlnaDtLcj
--HG--
extra : rebase_source : bef6e3e7e18c375262cec63e2bf84bf365e288a4
Initialize browserDOMWindow and any pending "geckoview-window-created"
observers in onInitBrowser, before the browser is bound to the window.
MozReview-Commit-ID: DmA7PckonGO
--HG--
extra : rebase_source : 9a97772665bd4a4504c6597bd136f778e2fc18b5
Several modules could use an "init browser" phase, where the browser or
the environment has to be initialized before the browser element is
bound to the window.
MozReview-Commit-ID: AoNgJy6QeNA
--HG--
extra : rebase_source : 7f4b4ef173c60d8e0aa4ea08c90d08639fc9b61d
Only unregister listeners explicitly. Also clean up the EventProxy code
a little.
MozReview-Commit-ID: 1U98BbGwfO7
--HG--
extra : rebase_source : 999cb50449301756d2625cbafb4b6f665e315d05
init(), onSettingsUpdate(), register(), and unregister() in
GeckoView(Content)Module.jsm are all expected to be overridden. Make
their naming consistent by always using the "on" prefix, similar to
our Java callback naming in GeckoSession.
MozReview-Commit-ID: K3CcPmm2YHs
--HG--
extra : rebase_source : d2963fd597dc8db80c548f45cd19dc5162455d21
Map generally works better than object as key-value stores.
MozReview-Commit-ID: 3BEYcRUHpW7
--HG--
extra : rebase_source : cb3e5193e4cd74f059054e14d401087b5cde87ef
I've also manually verified that no other references to HANDLE_EINTR are
wrapping a close() in any less syntactically obvious way.
MozReview-Commit-ID: 3KkBwFIhEIq
--HG--
extra : rebase_source : 4e79a70b3be22a7721b6f85b19ee5a31c98df456
This is based on the current security/sandbox/chromium version of eintr_wrapper.h,
taken from upstream commit 937db09514e061d7983e90e0c448cfa61680f605.
I've edited it to remove some things that aren't relevant to us: the
debug-mode loop limit in HANDLE_EINTR, because we don't seem to be
having the problem it's meant to fix and it risks regressions, and
references to Fuchsia, which we don't (yet) support. I also kept the
original include guards (the file path has changed upstream).
What this patch *does* do is add IGNORE_EINTR and modernize the C++
slightly (using decltype instead of nonstandard typeof).
MozReview-Commit-ID: BO4uQL9jUtf
--HG--
extra : rebase_source : ab3343c6d93e0ce753859217a55af131a0c4ea68
Although they still happen in the same transaction, they are done in two
separate frame messages. This results in better encapsulated code on the
C++ side since we don't have to pass around an array of properties, and
will simplify future changes to update these properties at render time
rather than at GenerateFrame time.
MozReview-Commit-ID: 9qUkHX7gmD1
--HG--
extra : rebase_source : 15a319ba270eb1783815c514ae05c6a72e323dac
