`|mach lint -f treeherder|` expects lints to not fail ever, if a lint fails it's
just ignored. This means that when our javadoc errors out and fails the build
all lints are ignored.
To avoid that we add `failOnError = false` to the javadoc job so that we can
finish the build and actually report the errors.
This patch also adds gradle output `|mach lint|` to make it easier to
diagnose errors in the lint.
Differential Revision: https://phabricator.services.mozilla.com/D77373
This crash hits when a `RemoteException` is thrown during `onServiceConnected`.
We `unbind`, which destroys all our bookkeeping data. During this destruction,
we also attempt to retrieve the pid, which fails because we lost our binding
before we had a chance to retrieve it.
This patch adds a new exception to be thrown in this case, which we explicitly
catch in `removeContentConnection`.
Differential Revision: https://phabricator.services.mozilla.com/D77135
In Bug 1622749 a user preference for where to open new documents (from a
service worker notification) was temporarily overriden in order to quickly fix
a crash that was happening in mozilla::dom::ClientOpenWindow. The crash was
ocurring when the pref "browser.link.open_newwindow" was set to 2, meaning new
documents are opened in a new window, instead of a new tab. The reason the
browser crashed is because the path for opening a new document is different
depending on the current user setting, and in NEWWINDOW case we did not get a
browsing context returned when calling mozilla::dom::OpenWindow which resulted
in a failed assertion.
The solution is to pass in a callback to mozilla::dom::OpenWindow as part of
nsOpenWindowInfo object, and invoke that callback with a corresponding
BrowsingContext in nsFrameLoader when that browsing context is ready.
After we call mozilla::dom::OpenWindow, we wait on a promise, that will be
resolved when the callback is invoked, before executing the rest of the code
that depends on the browsing context for a newly opened document being
available.
Differential Revision: https://phabricator.services.mozilla.com/D72745
I'm keeping this patch as simple as possible so that we can uplift to beta.
I'll sort out the rest of this in follow-up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D76333
I'm keeping this patch as simple as possible so that we can uplift to beta.
I'll sort out the rest of this in follow-up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D76333
I don't think all this complexity is worth it for having a
marginally-more-realistic testing story. Using the pref just works and we should
do that, I think.
Differential Revision: https://phabricator.services.mozilla.com/D59980
`GeckoProcessManager.buildLogMsg` requires a successful bind to construct its
message, but its only remaining callsite is only invoked when a bind fails,
so it blows up.
This patch eliminates `buildLogMsg` and just changes the callsite to use
a string literal.
Differential Revision: https://phabricator.services.mozilla.com/D76086
* We modify connection management such that we now use more specific connection
types for {content, non-content, socket process} connections.
* We attach a native counterpart to the `GeckoProcessManager.ConnectionManager`
instance that listens for app foreground, app background, and when the
socket process is enabled, network state events.
* On app background, all non-content processes are assigned BACKGROUND priority.
Even though backgrounding the app will cause Android to drop all child
processes' priority regardless of our priority settings, we still do this as
to indicate to Android that these processes are relatively less important
than our parent process.
* When the socket process is enabled, we drop its priority when we detect that
we have no network connectivity. Note that the network management code does
the Right Thing if network connectivity changes while our app was in the
background: we receive the network state change event once we return to
foreground, therefore we do not need to do any special handling ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D74478
I'm wondering whether Gecko's response to noticing that the child process was
killed is causing some notifications on the launcher thread to arrive out of
order from others. Removing the kill since we can just let Android handle
process termination.
Differential Revision: https://phabricator.services.mozilla.com/D75416
Since this is so common, let's reserve the `AssertionError` for debug builds.
In non-debug builds we will throw a `ServiceAllocator.BindException` which
will be caught and used for completing the bind promise.
GeckoProcessManager will retry unbinding and restarting the process, which
hopefully will mitigate the problem.
We also make some improvements to exception handling hygeine.
Differential Revision: https://phabricator.services.mozilla.com/D75415
Currently `unbind()` is more or less synchronous, but since those semantics may
change in the future, for the sake of cleanliness we should ensure that our
reaction is linked to `unbindResult`.
Differential Revision: https://phabricator.services.mozilla.com/D75414
In bug 1470348 we started to detach all SurfaceTextures from the
current GL context in CompositorOGL::Pause(). This was required for
VR, so that when the VR presentation was entered the SurfaceTextures
could be attached to the VR context instead.
When RenderCompositorEGL was implemented for webrender, we copied the
call to detach from CompositorOGL. However, due to extra complexity in
webrender's threading model, this is causing assertion failures.
VR no longer relies upon the SurfaceTextures being detached when the
compositor is paused, as it now uses its own SurfaceTexture
set. Therefore we can remove the detach call from both
CompositorOGL::Pause and RenderCompositorEGL::Pause.
Differential Revision: https://phabricator.services.mozilla.com/D74832
1. `GeckoProcessManager.ConnectionManager.onStartComplete` is called later than
it ideally should be; it would be better to do this as soon as binding is
complete, rather than as soon as `start` is complete. To accomplish this:
* We rename `onStartComplete` to `onBindComplete` and call it as soon as we
have successfully bound.
* We call `IChildProcess.getPid` as soon as we're bound and immediately clean
up if that fails.
* This implies that `getPid` should always have a pid and should not need to
call into `IChildProcess` during the remaining lifetime of the connection.
This allows us to eliminate exception throwing from `getPid`, and thus we may
also remove `getPidFallible`.
* This also means that we no longer need to explicitly call `getPid` in
`GeckoProcessManager.preload`.
2. We also use `XPCOMEventTarget.runOnLauncherThread` so that we do not need to
bounce through the launcher thread's event queue unnecessarily.
3. I noticed that we do not unbind the connection if the start fails but we
are not retrying. We should be unbinding regardless of whether we are going
to retry.
Differential Revision: https://phabricator.services.mozilla.com/D74500
Installed privileged addons in GeckoView sometimes need to send messages from
content scripts. Today we use the in-memory flag `ALLOW_CONTENT_MESSAGING` to
allow a specific built-in addon to send messages from content scripts, but for
installed extensions we need a way to persist this flag.
To do this, this patch introduces a new privileged permission
`nativeMessagingFromContent`, when this permission is present in the manifest,
the addon will be allowed to send native messages from content scripts (note:
the addon will also need `nativeMessaging` as usual).
When the permission is not present, any attempt to send a native message from a
content script will result in an error, similarly to what happens before this
patch.
Differential Revision: https://phabricator.services.mozilla.com/D72976
Sometimes extensions call tabs.create immediately on startup. In that case the
delegate may not be attached yet. To avoid losing these messages we store them
until a delegate is attached.
This also includes a refactoring to unify behavior for delegates. Eventually I
want to factor out delegates similarly to what happens in GeckoSession today.
Differential Revision: https://phabricator.services.mozilla.com/D72975
We use this to send a default action to the embedder, but if no one is
listening there's no point, and it causes problems in tests because sometimes
the delegate is attached / reattached too quickly and the second delegate will
end up getting two messages by mistake.
Differential Revision: https://phabricator.services.mozilla.com/D72974
Bogdan Tara
Agi Sferro
Eugen Sawin
Aaron Klotz
Anny Gakhokidze
Nazım Can Altınova
Emilio Cobos Álvarez
John Lin
Dylan Roeh
Makoto Kato
Gabriel Luong
Jamie Nicol
owlishDeveloper
Nikita Kozhemiakin
Csoregi Natalia
Mihai Alexandru Michis