Don't send window changed event if a11y has been turned off in the mean
time.
Differential Revision: https://phabricator.services.mozilla.com/D5192
--HG--
extra : moz-landing-system : lando
When entering and exiting immersive mode multiple time (~30) the WebGL context can be lost. This is caused because GeckoSurfaceTexture things there are more than 200 textures created.
Differential Revision: https://phabricator.services.mozilla.com/D4235
--HG--
extra : moz-landing-system : lando
In my opinion this is an altogether nicer way of setting and resetting temporary
StrictMode exceptions. The only fly in the ointment is that this causes a
warning about a technically unused variable that subsequently needs suppressing.
Differential Revision: https://phabricator.services.mozilla.com/D4889
--HG--
extra : rebase_source : 706af6665b709c2ed29730cf266c3267417e4a52
extra : source : 54a3c14eff313baade8bc40523f69fa9c7aaba75
That way, we only add that notification channel if the updater really is active,
i.e. not if we've been installed from the Play Store.
Unfortunately, using the UpdateServiceHelper requires a Context, so adding/re-
moving the UPDATER_CHANNEL_TAG cannot be done during variable initialisation.
Differential Revision: https://phabricator.services.mozilla.com/D4890
--HG--
extra : moz-landing-system : lando
Previously, most of our notifications were silent, so we adopt a default
priority of IMPORTANCE_LOW instead of IMPORTANCE_DEFAULT.
Since we cannot change the priority setting for existing users on Nightly any
more, we technically have to retire the old default channel and replace it by
a new channel with a different ID. While in a way this is circumventing Google's
API design and destroys any existing customisation users have set for that
channel, we are only using this exceptionally to *lower* the initial priority of
our default notification channel, which we accidentally set too high. Besides,
it is unlikely that there are many users who really want to receive all kinds of
random Firefox notifications with a high priority.
Differential Revision: https://phabricator.services.mozilla.com/D4364
--HG--
extra : moz-landing-system : lando
nsISHEntry.index is readonly, but if you pass `true` as getEntryAtIndex()'s
second argument, nsISHEntry.index will be modified. This is pretty gross.
This patch changes `index` so it's not readonly (because it's not!) and removes
getEntryAtIndex()'s second argument.
--HG--
extra : rebase_source : c519d77fcc1c3bda2f260b5888ce9cd0f6cfdab5
This removes a number of references to rules that are now deprecated or removed from ESLint.
- no-native-reassign is replaced with no-global-assign
- no-spaced-func is replaced with func-call-spacing (where enabled)
Depends on D4944
Differential Revision: https://phabricator.services.mozilla.com/D4946
--HG--
extra : moz-landing-system : lando
Added a default channel for Leanplum push notifications as fallback to cover the cases where we receive
push notifications from server with an invalid channel and the case where there are no channels configured
on server.
Provided a valid default icon for push notifications in Leanplum required for fallback strategy.
Differential Revision: https://phabricator.services.mozilla.com/D4704
--HG--
extra : moz-landing-system : lando
If we don't have a saved session, we do nothing. If somebody called setSession
beforehand, we continue using that session, otherwise we create a fallback
session in onAttachedToWindow().
If we have a saved session and nobody called setSession, we use the saved
session. If the saved session was closed and doesn't have a runtime, we use the
default runtime as a fallback.
If we have both a saved session and somebody already called setSession, we
transfer what can be transferred from the saved session, unless the saved
session is closed and the session from setSession is open.
If the saved session was open, we use its runtime as well going forward (since
transferring the state from an open session transfers the window and the runtime
as well), otherwise we keep the old mRuntime.
Differential Revision: https://phabricator.services.mozilla.com/D4711
--HG--
extra : moz-landing-system : lando
Added an extra check for package name for a better user experience, because the push notifications with "about" protocol
in the URL message were still firing the chooser dialog.
Differential Revision: https://phabricator.services.mozilla.com/D4578
--HG--
extra : moz-landing-system : lando
Instead of stopping the foreground service whenever ACTION_PAUSE was triggered,
I created a new event where we notify the service to clear its foreground state.
Cleared usages of the NotificationManager and the onGoing attribute of the
MediaNotification because they are redundant. As of Android 4.3 a service in the
foreground state will always force the notification to be persistent and callling
stopForeground(false) will clear the onGoing flag while maintaining the notification.
Differential Revision: https://phabricator.services.mozilla.com/D4567
--HG--
extra : moz-landing-system : lando
From the PIP window the user can either return to the fullscreen app or exit
it entirely.
Fullscreen and subsequently hiding the status bar should only be done if the
user is returning to the app.
Differential Revision: https://phabricator.services.mozilla.com/D4676
--HG--
extra : moz-landing-system : lando
In my opinion this is an altogether nicer way of setting and resetting temporary
StrictMode exceptions. The only fly in the ointment is that this causes a
warning about a technically unused variable that subsequently needs suppressing.
Differential Revision: https://phabricator.services.mozilla.com/D4889
--HG--
extra : source : ac7659d4135e270b6d787499680aefc39a01fb4f
extra : histedit_source : bdffd8eee3fcf1e705316de6e84da7c7aac9340a
Doing so allow to use try-with-resources on all API levels supported by us, not
just starting from API19.
Unfortunately this step also introduces some additional ambiguities in overload
resolution, which means that one of GeckoResult's "then" overloads needs to be
renamed.
Differential Revision: https://phabricator.services.mozilla.com/D4887
--HG--
extra : rebase_source : 7173395484a9616ce739e9d2ba3aa0b8410be386
extra : source : 66955d05bb86c25b1fcb81d60b38be95018d09ca
Some common javadoc mistakes are logged as warnings and are being
overlooked. javadoc does not support warning-as-error natively, so this
patch scans the javadoc output in gradle and makes the task fail if any
warnings are detected.
Differential Revision: https://phabricator.services.mozilla.com/D3925
Most of the ReaderMode.jsm and Readability.js code is only needed when we
actually need to render a document in reader mode, but also winds up loaded
into any process where we ever check if a page is readerable. This winds up
wasting a huge amount of memory (and probably a huge amount of CPU time)
loading code which is almost never used.
This patch splits ReaderMode.jsm into two modules, one for checking
readability, one for actually entering reader mode. It also separates out the
isProbablyReaderable checks from Readability.js, since the overhead of loading
that script before it's needed is unsupportable.
This means we're probably going to need some effort to keep Readerable.jsm and
Readability.js in sync, but the code in question is pretty trivial, so it
shouldn't be too difficult.
Differential Revision: https://phabricator.services.mozilla.com/D3687
--HG--
rename : toolkit/components/reader/Readability.js => toolkit/components/reader/Readability-readerable.js
rename : toolkit/components/reader/ReaderMode.jsm => toolkit/components/reader/Readerable.js
extra : rebase_source : 66712057591ae20dd66234e3dc78fbba90a6914e
extra : amend_source : f908f62f49ea54b9099ddb87d9f2fc11f12d4dee
Though we can't write automation tests for this, I have confirmed that the input
device added/removed are properly notified to 'browser.xul'. Unfortunately the
notifications don't reach to conent documents because of bug 1478212, but I've
also confirmed they did reach to content documents with replacing
MediaFeatureValuesChanged with MediaFeatureValuesChangedAllDocuments in
nsPresContext::RefreshSystemMetrics().
Differential Revision: https://phabricator.services.mozilla.com/D3303
There is no API that we can tell which input device is the primary pointer
device on Android, so we assume that the first pointer-type input device
in the list of InputDevice.getDevice is the primary one.
Test results on L-01F (a variant of LG-G2):
- Normal boot
The touchscreen is the primary device
- Plugged a mouse
The touchscreen is the primary device
- Boot with a plugged mouse
The mouse is the primary device
- Plugged off the mouse
The touchscreen is now the primary device
- Plugged the mouse again
The touchscreen is the primary device
Classification in getPointerCapablities refered to chrome impelementation [1].
In addition to the classification, we add SOURCE_JOYSTICK as a 'COARSE' and
'HOVER_CAPABLE' device.
[1] d4c8983688/ui/android/java/src/org/chromium/ui/base/TouchDevice.java (72)
Differential Revision: https://phabricator.services.mozilla.com/D3302
To avoid cluttering our notification settings on builds not using the built-in
updater, we only add that channel when required.
Passing a null channelId to the system NotificationManager, which can then
happen if someone attempts to use the UPDATER channel anyway, even though
MOZ_UPDATER is false, is safe. It just means that the NotificationManager will
return the system's default channel, which will silently swallow any
notifications posted to it from apps targeting Android O or above.
Differential Revision: https://phabricator.services.mozilla.com/D4584
--HG--
extra : moz-landing-system : lando
Fix Lollipop crashes because of android.content.res.ColorStateList.addFirstIfMissing()
The default app theme will be applied for the material Date/Time pickers on
API 21 and API 22. After this, on API >=23 they will be Photon themed.
Differential Revision: https://phabricator.services.mozilla.com/D4464
--HG--
extra : moz-landing-system : lando
This patch removes the 'ScreenOrientationInternal' type from
dom/base/ScreenOrientation.h and moves it into the
HalScreenConfiguration.h header, renaming it simply to 'ScreenOrientation'
in the process. This has several knock-off effects:
- It allows files that needed ScreenOrientationInternal to include a much
smaller header than before
- It greatly reduces the number of headers pulled in when including Hal.h
- It clarifies the role of the type. The 'Internal' part in the name had
nothing to do with it being part of the implementation. The type was public
and called that way only to avoid clashing with the 'ScreenOrientation'
class. Since we moved it into a different namespace it can be renamed
safely.
- It allows a file that was manually re-declaring 'ScreenConfigurationInternal'
type to use the original one
- Finally this fixes a few files which were missing headers they actually
required but that would still build because unified compilation put them into
units that already had those headers thanks to ScreenConfiguration.h
Differential Revision: https://phabricator.services.mozilla.com/D4458
--HG--
extra : moz-landing-system : lando
Add a GeckoSession property too specify if media should be suspended when the session is inactive.
Differential Revision: https://phabricator.services.mozilla.com/D4472
--HG--
extra : moz-landing-system : lando
MozReview-Commit-ID: 1HWEStKaGVl
Bug 1476552 part 1 - Add @NonNull/@Nullable annotations to GeckoSession::WebResponseInfo for Kotlin interoperability
Bug 1476552 part 2 - Make GeckoSession::WebResponseInfo static
MozReview-Commit-ID: 4ce92G7i2nz
Differential Revision: https://phabricator.services.mozilla.com/D2885
--HG--
extra : moz-landing-system : lando
When entering and exiting immersive mode multiple time (~30) the WebGL context can be lost. This is caused because GeckoSurfaceTexture things there are more than 200 textures created.
Differential Revision: https://phabricator.services.mozilla.com/D4236
--HG--
extra : moz-landing-system : lando
This fixes some errors reported by infer on GeckoView that are not related to threading.
Differential Revision: https://phabricator.services.mozilla.com/D3787
--HG--
extra : moz-landing-system : lando
Add some tests for the Oreo auto-fill frontend, similar to the tests for
the a11y auto-fill frontend. However, because these tests depend on the
ViewStructure class, they require SDK 23+ to run.
Differential Revision: https://phabricator.services.mozilla.com/D3810
Another reason to backout is that there may be other subtle breakage
like bug 1478623 and bug 1478269 and we don't have a lot of test
coverage on Android.
This also removes the trivial tests for geckoview_example that were
causing problems.
Differential Revision: https://phabricator.services.mozilla.com/D3991
--HG--
extra : moz-landing-system : lando
The fragment is also used to handle intents launched through GeckoAppShell.
openUriExternal(), such as e.g. when launching downloaded files from
about:downloads.
The synchronous code path when not in private browsing is already covered by the
code added in bug 1450449, but the async path through the fragment when in
private browsing needs to be handled separately.
Differential Revision: https://phabricator.services.mozilla.com/D3916
--HG--
extra : moz-landing-system : lando
Fix running robocop tests on debug builds.
This patch fixes multidex issues when running robocop on debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D3422
--HG--
extra : moz-landing-system : lando
Add a frontend for the Oreo auto-fill API in SessionTextInput, which
processes events from Gecko and provides consumer APIs that match the
Oreo auto-fill APIs. GeckoView then forwards the necessary calls to
SessionTextInput.
Differential Revision: https://phabricator.services.mozilla.com/D3538
Add an auto-fill frontend that listens to events from Gecko. It
populates accessibility nodes for input fields and sends accessibility
events, in order to support auto-fill clients that use accessibility
services to perform auto-fill.
Differential Revision: https://phabricator.services.mozilla.com/D3254
Add an auto-fill backend in GeckoViewContent.js that detects fields on
the page and sends information about the fields to Java through events.
Differential Revision: https://phabricator.services.mozilla.com/D3253
Make the session store event listeners inline, because it makes the code
more readable, and also because auto-fill requires a pageshow listener
that is always registered, so the existing pageshow listener needs to be
moved elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D3252
Make a distinction between a session being active (i.e. being visible)
and it being focused. More than one session may be active at a time, but
only one session is focused at a time. This means the focused session is
always active, but an active session may not be focused.
Also, manage setting of active/focused states in GeckoView itself, so
consumers don't generally have to worry about these states.
Differential Revision: https://phabricator.services.mozilla.com/D3251
Move the AccessibilityNodeProvider implementation under
SessionAccessibility, to reduce the indent of the code.
Also make all methods in SessionAccessibility.Settings static to make
the code easier to follow.
Differential Revision: https://phabricator.services.mozilla.com/D3250
Add a frontend for the Oreo auto-fill API in SessionTextInput, which
processes events from Gecko and provides consumer APIs that match the
Oreo auto-fill APIs. GeckoView then forwards the necessary calls to
SessionTextInput.
Differential Revision: https://phabricator.services.mozilla.com/D3538
Add an auto-fill frontend that listens to events from Gecko. It
populates accessibility nodes for input fields and sends accessibility
events, in order to support auto-fill clients that use accessibility
services to perform auto-fill.
Differential Revision: https://phabricator.services.mozilla.com/D3254
Add an auto-fill backend in GeckoViewContent.js that detects fields on
the page and sends information about the fields to Java through events.
Differential Revision: https://phabricator.services.mozilla.com/D3253
Make the session store event listeners inline, because it makes the code
more readable, and also because auto-fill requires a pageshow listener
that is always registered, so the existing pageshow listener needs to be
moved elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D3252
Make a distinction between a session being active (i.e. being visible)
and it being focused. More than one session may be active at a time, but
only one session is focused at a time. This means the focused session is
always active, but an active session may not be focused.
Also, manage setting of active/focused states in GeckoView itself, so
consumers don't generally have to worry about these states.
Differential Revision: https://phabricator.services.mozilla.com/D3251
Move the AccessibilityNodeProvider implementation under
SessionAccessibility, to reduce the indent of the code.
Also make all methods in SessionAccessibility.Settings static to make
the code easier to follow.
Differential Revision: https://phabricator.services.mozilla.com/D3250
Bug 1481139 - p1: handle invalid file descriptors.
Bug 1481139 - p2: add dummy fds for GMP process.
Two file descriptors were added in bug 1438678 and 1471025 for content/child
process but not GMP process, and it breaks the IPC channel on Android.
Add dummy values to make it work for now before bug 1440207 clean up the mess.
Differential Revision: https://phabricator.services.mozilla.com/D3541
--HG--
extra : moz-landing-system : lando
The previous implementation attempted to delete files from /res/fonts (i.e.
root). I don't believe this was intended either:
https://bugzilla.mozilla.org/show_bug.cgi?id=878674#c0 indicates the fonts
directory should be inside the data dir of the application. The crash occurs
when the /res/fonts directory exists (only some devices) but the user doesn't
have read access. If the user has write access, our code may actually delete
these system files: uh oh!
My fix is to change the deletion from /res/fonts to <dir>/res/fonts. I verified
this fix worked by creating a clean profile, adding dummy files to the
res/fonts dir, and making sure only the correct ones were deleted (in zsh):
export DIR=/data/data/org.mozilla.fennec_mcomella; \
adb shell pm clear org.mozilla.fennec_mcomella && \
adb shell mkdir -p $DIR/res/fonts && \
for i in touch.ttf lol.rdf; do adb shell touch $DIR/res/fonts/$i; done && \
adb shell ls $DIR/res/fonts
MozReview-Commit-ID: 8atpcjYjGu0
Now that GeckoScreenOrientation generally offers notifications of screen
orientation changes, the PromptService no longer needs to do its own orientation
tracking and require to be fed orientation changes from each activity using it.
MozReview-Commit-ID: K7KbDsQip7b
--HG--
extra : rebase_source : 8b447d9db079794c9ad231a31a52f2787ab742ce
As of bug 1475875, cached screen data is now held by Gecko, so
- we no longer need to cache the screen size (retrieval of which can be
expensive when called en masse, as required e.g. by font inflation) within
GeckoAppShell, and
- we need to trigger a refresh of that data instead when the activity
orientation changes.
MozReview-Commit-ID: JsY6sBCcOih
--HG--
extra : rebase_source : f286f3b01732bd724da3988c4713adb7329a5fae
By moving the calls to GeckoScreenOrientation.update() into GeckoView, any app
using a GeckoView will automatically update the screen orientation in Gecko,
too, without any further action being required by the embedding app.
The synchronisation around GeckoScreenOrientation.update()/(un)lock() is
required for the following scenario:
If (un)locking of the screen orientation as requested by Gecko caused the
actual screen orientation of the app to change, there are two ways in which this
will cause our internal screen orientation to be updated:
1. Either the call to delegate.setRequestedOrientationForCurrentActivity
(happening on the Gecko thread if the original request to (un)lock came from
Gecko) returns first and update() is subsequently first called from the Gecko
thread, too, meaning the onOrientationChange notification to Gecko can occur
synchronously as well. In that case, as soon as (un)lock returns to Gecko,
querying our internal screen orientation will return the correct value.
2. Or else the GeckoView.onConfigurationChanged() call resulting from the screen
rotation manages to call GeckoScreenOrientation.update() first and does so
from the Android UI thread. This means that the onOrientationChange
notification will be redispatched asynchronously to the Gecko thread, while
the Gecko thread's call to GeckoScreenOrientation.update() will return early
without doing any work, as the screen orientation had already been previously
updated by the UI thread.
As a result,there will be a period of time between the Gecko thread returning
from GeckoScreenOrientation.(un)lock() and the onOrientationChange
notification finally executing where querying the internal screen
orientation will not yet return the new orientation. This can cause problems
for Gecko (test) code that expects to (un)lock the orientation and then be
able to immediately query the new, changed orientation after the call to
(un)lock returns.
Without additional measures in place, there are no guarantees at what point
the GeckoView will receive the onConfigurationChanged() call in relation to the
request to change the activity's orientation making its way back to (un)lock().
Therefore, we add synchronisation such that no other thread will be able to up-
date the screen orientation in GeckoScreenOrientation while another thread is
still busy (un)locking the screen orientation.
MozReview-Commit-ID: 5s5NEJcuS0p
--HG--
extra : rebase_source : cbfbc6da99aa23af4eee8c4bf6018359f9e71304
The call to mSession.transferFrom(ss.session) in the line above also transfers
the window from ss.session into mSession, which means we subsequently won't be
able to retrieve a runtime from ss.session any more, thereby defeating the goal
of calling mRuntime = ss.session.getRuntime().
This case is encountered e.g. when the containing activity is destroyed and sub-
sequently recreated after a configuration change that isn't handled by the app,
e.g. screen rotation in the GeckoView example app.
MozReview-Commit-ID: 5YGskdLZWqw
--HG--
extra : rebase_source : 3293fcaaf645706133531cb0180b6514a289b612
Once responsibility for notifying GeckoScreenOrientation of potentially changed
screen orientations moves from GeckoApp into GeckoView, the former will no
longer be able to benefit from the return value of calling GeckoScreen-
Orientation.update(), indicating whether the orientation actually changed or in
fact remained the same.
GeckoApp however requires that information in order to reset/refresh parts of
the UI when the orientation changes, and since GeckoScreenOrientation is already
doing all the work of tracking screen orientation changes, we don't want to have
to partially duplicate those efforts again in GeckoApp.
Instead, we introduce a mechanism for GeckoScreenOrientation to notify
interested parties on the Android app side as well.
The GeckoScreenOrientation.update() call in GeckoApp.onResume() is removed
completely (as opposed to merely removing the refreshChrome() bit) at this stage
already because it is unnecessary. If any screen rotation happened while the
activity was in background, it will receive an onConfigurationChanged() call
anyway before being resumed again.
MozReview-Commit-ID: Ila1evcj8Ud
--HG--
extra : rebase_source : f342800628f930d717fe346779894793a1bac0e9
