The threading model described in the javadoc (ExoPlayer.java#92 in tree)
requires that the player is accessed from a single thread. However current
GeckoHlsPlayer implementation violates this rule and uses the player from
Gecko main thread and other media task queues. Introduce methods to execute
code asynchronously and synchronously for GeckoHlsPlayer to follows the rule.
Also add comments documenting thread usages for some instance variables and
assertions in the begining of methods that need to be on the player thread
to help debugging.
Differential Revision: https://phabricator.services.mozilla.com/D85668
FlipScreenPixels was heap-allocating and leaking a ScopedMap object, which kept
the surface alive.
Instead, we want to keep the surface alive just long enough to copy its data
into a Java Bitmap object. This copy needs to be done on the C++ side so that
we're sure that it happens while the surface data exists. After that, the Java
code can hold on to the resulting Bitmap object as long as it wants, since the
Bitmap then owns its own data.
The ScreenshotBuilder GeckoView API allows users to specify the bitmap object
that will be used. So rather than creating a new Bitmap object in the C++ code,
we pass the target bitmap into the C++ code that performs the copy.
As a drive-by fix, this patch eliminates another copy at the start of
FlipScreenPixels by replacing a call to `gfx::CreateDataSourceSurfaceFromData`
(which copies) with a call to `gfx::Factory::CreateWrappingDataSourceSurface`
(which doesn't copy).
It would be nice if we could eliminate another copy here, by performing the flip
during the copy into the Bitmap object. But I don't think there's a way to do
that. Also, for optimal performance, we probably want to get an AHardwareBuffer
object from the compositor and wrap that into a Bitmap.
Furthermore, the patch adds a check that makes sure the draw target was created
successfully before accessing it (throwing an exception if not).
Differential Revision: https://phabricator.services.mozilla.com/D85490
FlipScreenPixels was heap-allocating and leaking a ScopedMap object, which kept
the surface alive.
Instead, we want to keep the surface alive just long enough to copy its data
into a Java Bitmap object. This copy needs to be done on the C++ side so that
we're sure that it happens while the surface data exists. After that, the Java
code can hold on to the resulting Bitmap object as long as it wants, since the
Bitmap then owns its own data.
The ScreenshotBuilder GeckoView API allows users to specify the bitmap object
that will be used. So rather than creating a new Bitmap object in the C++ code,
we pass the target bitmap into the C++ code that performs the copy.
As a drive-by fix, this patch eliminates another copy at the start of
FlipScreenPixels by replacing a call to `gfx::CreateDataSourceSurfaceFromData`
(which copies) with a call to `gfx::Factory::CreateWrappingDataSourceSurface`
(which doesn't copy).
It would be nice if we could eliminate another copy here, by performing the flip
during the copy into the Bitmap object. But I don't think there's a way to do
that. Also, for optimal performance, we probably want to get an AHardwareBuffer
object from the compositor and wrap that into a Bitmap.
Furthermore, the patch adds a check that makes sure the draw target was created
successfully before accessing it (throwing an exception if not).
Differential Revision: https://phabricator.services.mozilla.com/D85490
This is timing issue when using iFLYTEC keyboard in Xiaomi App Store.
Although replace text transaction often dispatch dummy text change, it may be
unnecessary when other text change is already in text change queue. This issue
occurs if dummy text change is dispatched in the queue and other text change
is also dispatched in the queue.
`AddIMETextChange` merges old text change with newer text change when its range
is overlapped, but it doesn't consider range is same. So if same range, we
should adjust old end simply.
GV-junit test case emulates this situation, but since this is timing issue,
we won't reproduce this by this test case. But it is useful to check future
regressions.
Differential Revision: https://phabricator.services.mozilla.com/D84140
I just tested it on Fenix nightly and it works great. It better do
actually, as most of the code is shared with find-in-page.
See bug 750051 for when this was blocked. I don't think that was
properly understood at the time, but at this point the divergence from
desktop seems gratuitous.
This has caused compat issues in the past.
Differential Revision: https://phabricator.services.mozilla.com/D84758
This avoids problems where a foreground tab tries to communicate with a background
tab via `window.opener`, but is unable to because the background tab
is suspended.
Differential Revision: https://phabricator.services.mozilla.com/D83693
Uses of `-moz-appearance: none` are changed to `appearance: none`.
Uses of other values that are simply reverting the appearance back to
its default are changed to `appearance: auto`.
Uses of values in UA sheets that are defining the inherent appearance of
widgets are changed to:
appearance: auto;
-moz-default-appearance: <value>;
since those values are either no longer supported on (-moz-)appearance,
or are still supported but only in some limited form.
There are some uses of `-moz-appearance: textfield` on <input
type=number> elements that are renamed to `appearance: textfield`.
Differential Revision: https://phabricator.services.mozilla.com/D83430
To sync Gecko's text with Java text correctly, I would like to add more text
and selection check each `InputConnection.setComposingText` call.
Differential Revision: https://phabricator.services.mozilla.com/D83464
Added private/protected, unimplemented versions of the necessary Java
classes for the menus API, set up event dispatching and listening.
Differential Revision: https://phabricator.services.mozilla.com/D82383
When using the `tabs.query` API in a popup (e.g. a browserAction popup)
extensions expects to refer to the window where the popup is.
On mobile we don't really have a concept of window in the way that extensions
expect us to have, we also treat all tabs as belonging to separate tabs.
To make the behavior of the extension API more consistent with desktop, we
pretend that the popup belongs to whatever the top tab is at the time.
Differential Revision: https://phabricator.services.mozilla.com/D82769
We use this object on the Java side to open the popup and without this change
we don't look at the default popup URL when the tab-specific one is not
defined.
Differential Revision: https://phabricator.services.mozilla.com/D82767
mozStorage used to read prefs on service init, because they could only be read
on the main-thread. When service init was moved earlier, it started trying
to read prefs too early, before the profile was set up, thus it ended up always
reading the default value.
This patch moves the only relevant pref to mirrored StaticPrefs that can be accessed
from different threads, and removes two preferences that apparently are not necessary
(they have been broken from a long time) for now.
In particular, providing a global synchronous setting is a footgun, each consumer should
decide about their synchronous needs, rather than abusing a dangerous "go fast" setting.
The page size is something we don't change from quite some time, and it's unlikely to be
used to run experiments in the wild before doing local measurements first, for which Try
builds are enough.
The remaining exclusiveLock pref is a bit controversial, because in general exclusive lock
is better for various reasons, and mostly it is necessary to use WAL on network shares.
Though developers may find it useful for debugging, and some third parties are doing
dangerous things (like copying over databases) to work around it, for which it's safer to
provide a less dangerous alternative.
Note exclusive lock only works on Unix-derived systems for now (no Windows implementation).
Finally, this introduces a fallback to exclusive lock, so that if a third party is using our
databases, so that we can't get an exclusive lock, we'll fallback to normal locking.
Differential Revision: https://phabricator.services.mozilla.com/D82717
Ricky Stewart
John Lin
Butkovits Atila
Sebastian Streich
Anny Gakhokidze
Markus Stange
owlishDeveloper
Agi Sferro
Dylan Roeh
Noemi Erli
sotaro
Makoto Kato
Emilio Cobos Álvarez
Jonathan Almeida [:jonalmeida]
Dorel Luca
Kris Maglione
James Willcox
Nathan Froyd
Cameron McCormack
Xidorn Quan
Cosmin Sabou
Grace Bramley-Simmons
Csoregi Natalia
Tiger Oakes
Marco Bonardo
Tom Prince