At this point, no code in mozilla-central references these.
In comms-central, the string is still used, but provided there
by local brand.properties and brand.dtd files.
Depends on D141860
Differential Revision: https://phabricator.services.mozilla.com/D141861
This is helpful when looking at logs from fenix in automation to answer
questions like, did the profiler start? Did it finish or did it crash before
then? Did it record any samples?
We had to add this logging temporarily to debug a test failure and it seemed
non-intrusive enough that we could keep it around long term.
Differential Revision: https://phabricator.services.mozilla.com/D141704
Added "prompts" to geckoview.js window to collect active prompts using the added
GeckoViewPrompterChild and GeckoViewPrompterParent.
Added a way to get and set the prompt message text, callback, and
accept prompt(), confirm(), and alert().
Differential Revision: https://phabricator.services.mozilla.com/D133927
This prevents a java NullPointerException when the
RemoteSurfaceAllocator returns a null Surface to the local
SurfaceAllocator instance.
Differential Revision: https://phabricator.services.mozilla.com/D140801
The exact error is
```
groovy.lang.MissingMethodException: No signature of method: groovy.util.FileNameFinder.getFileNames() is applicable for argument types: (File, String)
```
Differential Revision: https://phabricator.services.mozilla.com/D140689
The fact that isOpen is @AnyThread seems to be a mistake, I don't think we can
reliably tell a consumer if a session is open on a background thread.
Even with synchronized access to mWindow code like this would always be broken
on a background thread:
```
if (!session.isOpen()) {
session.open(sGeckoRuntime);
}
```
because another thread could open the session between the isOpen() and the
session.open statements.
This patch changes isOpen to @UiThread. I verified that all calls actually
happen on the UI thread, except for the calls in GeckoSessionSettings where we
are trying to handle the case where a session was closed and _then_ we would
allow modifying read-only settings. I think in that case we should ask the
embedder to use a new SessionSettings instance instead of forcing all calls to
be @UiThread.
Differential Revision: https://phabricator.services.mozilla.com/D137784
The fact that isOpen is @AnyThread seems to be a mistake, I don't think we can
reliably tell a consumer if a session is open on a background thread.
Even with synchronized access to mWindow code like this would always be broken
on a background thread:
```
if (!session.isOpen()) {
session.open(sGeckoRuntime);
}
```
because another thread could open the session between the isOpen() and the
session.open statements.
This patch changes isOpen to @UiThread. I verified that all calls actually
happen on the UI thread, except for the calls in GeckoSessionSettings where we
are trying to handle the case where a session was closed and _then_ we would
allow modifying read-only settings. I think in that case we should ask the
embedder to use a new SessionSettings instance instead of forcing all calls to
be @UiThread.
Differential Revision: https://phabricator.services.mozilla.com/D137784
There's no current use for setting `JS_BINARY` in `packager.mk`, so
remove it while we're here. I elected to make it easy to add new file
types to minify rather than to make it easy to specify `JS_BINARY`,
since the latter mechanism is strictly more general and could be used
in future for things other than minification.
Differential Revision: https://phabricator.services.mozilla.com/D138364
Even if platform implementation always returns error, `orientation.lock('any')`
is always successful. Because we don't wait for `LockDeviceOrientation`'s result
when current screen orientation is same as lock type. If
`LockDeviceOrientation` is failed, we should reject the promise.
Differential Revision: https://phabricator.services.mozilla.com/D137971
From https://w3c.github.io/screen-orientation/#apply-an-orientation-lock
> 7.2. Apply an orientation lock
>
> The steps to apply an orientation lock to a Document using orientation are as
> follows:
>
> 1. If the user agent does not support locking the screen orientation, return
> a promise rejected with a "NotSupportedError" DOMException and abort
> these steps.
So if orientation controller delegate isn't set, we should throw
`NotSupportedError`. But, actually, we throws `AbortError`, so this isn't
correct.
To return any DOM error from platform implementation of
`screen.orientation.lock`, I would like to change return value to
`GenericPromise`'s.
Differential Revision: https://phabricator.services.mozilla.com/D137970
If the GPU process crashes immediately after startup, before
GPUProcessHost calls getCompositorSurfaceManager, then the
getExistingConnection call will return null. This wasn't being
handled, resulting in a parent process crash due to a null pointer
exception.
This patch simply returns null from getCompositorSurfaceManager if it
cannot find the GpuProcessConnection. This will avoid the parent
process crash, allowing the GPU process crash to be handled
correctly (sending a crash report and restarting/disabling the GPU
process).
Differential Revision: https://phabricator.services.mozilla.com/D139943
This patch introduces a new system for building IPDL unit tests, which is
roughly inspired by the old cxx unit test design, however designed to work with
gtest. It re-uses the existing IPDLUnitTest process type, using static
constructors only present in xul-gtest to register child actor constructors and
ProcessChild implementations to avoid bloating xul.
The IPDLUnitTest actor is used as a backchannel to communicate test failures
from the child process back to the parent process, and manage the test's async
lifecycle more reliably.
The IPDLUnitTest process also needed to have various properties about how it was
initialized adjusted:
* The IPDLUnitTest process should now always load xul-gtest when running
gtests, by using the "Self" process type and adding a DYLD_LIBRARY_PATH override
on macOS where the "Self" process type cannot be used.
* The IPDLUnitTest process now initializes minimal XPCOM, and runs a
frankeneventloop to allow it to use XPCOM event loop structures such as
SpinEventLoopUntil in tests.
* Support for creating IPDLUnitTest processes on Android was added, as these
tests had never run on android before.
Differential Revision: https://phabricator.services.mozilla.com/D137170
Although the default value for isPrivileged is false in the
ExtensionData constructor, let's add the explicit value (false) so that
it's obvious that the default value is intended.
Differential Revision: https://phabricator.services.mozilla.com/D139725
Concurrency bug: this method accesses mutable state but is not synchronized so
the caller isn't guaranteed to see the latest values.
We fix it by using an AtomicReference. This slightly complicates the thread
policy (which is to otherwise synchronize access to mutable state) but avoids
the increased contention that could come from using synchronized for
consistency.
This is the only concurrency bug I found throughout my thread safety
documentation.
Differential Revision: https://phabricator.services.mozilla.com/D139199
getSample's callers are synchronized in the current implementation so there are
no concurrency bugs there but it can later be called by an unsynchronized caller
so I added synchronization to it and documented the thread safety guarantees.
Differential Revision: https://phabricator.services.mozilla.com/D139197
As used, the class is effectively immutable which provides some thread safety
guarantees so I updated the declarations so the class could take advantage of
that.
Effectively immutable classes need to be safely published in order to be thread
safe. I believe we could avoid the need for safe publishing (i.e. strengthen
thread safety guarantees) if we replaced the Frame[] type with a
thread safe data type (AtomicReferenceArray, a concurrent list, etc.).
Differential Revision: https://phabricator.services.mozilla.com/D139196
Like Frame, this class was not thread safe because it exposed mutable state.
However, it was being used in an immutable manner so it was trivial to make it
thread safe.
Differential Revision: https://phabricator.services.mozilla.com/D139195
This class was not thread safe because the fields in this class were mutable
and access to mutable state must be synchronized across threads. This class was
only used in an immutable fashion, however, so it was trivial to make it
immutable and thus thread safe.
Differential Revision: https://phabricator.services.mozilla.com/D139194
Root cause: some scripts in the content process were loaded before the script
cache was available there so these scripts were never written to the cache and
thus were never loaded from cache on subsequent runs, affecting performance.
These scripts listened for the app-startup topic.
This patch introduces a new topic to indicate when the script cache is init so
scripts previously listening to app-startup can listen to the new topic instead.
Differential Revision: https://phabricator.services.mozilla.com/D138501
Iulian Moraru
Ryan VanderMeulen
Eemeli Aro
mleclair
Butkovits Atila
Michael Comella
Makoto Kato
Cristian Tuns
Olivia Hall
Eitan Isaacson
Agi Sferro
edguloien
Mark Banner
Jamie Nicol
smolnar
Nick Alexander
Nika Layzell
Rob Wu
Narcis Beleuzu