I quickly tested on Fennec with the whole stack and I am able to list workers, inspect workers etc...
Could not see any issue at first glance.
Differential Revision: https://phabricator.services.mozilla.com/D16175
--HG--
extra : moz-landing-system : lando
We can receive GeckoSession.onCompositorDetached() before
GeckoSession.onCompositorReady() has run, so guard against this
by ensuring the compositor is attached in onCompositorReady().
Differential Revision: https://phabricator.services.mozilla.com/D16983
--HG--
extra : moz-landing-system : lando
Summary:
Login data is to be removed only from "about:logins" where the users that use
Sync are also informed about the perils of doing so.
Depends on D16027
Reviewers: JanH, #geckoview-reviewers
Reviewed By: JanH
Subscribers: flod
Bug #: 1473470
Differential Revision: https://phabricator.services.mozilla.com/D16029
--HG--
extra : rebase_source : f7b9a885333e2b8bab310037aeced2e76812b8aa
extra : histedit_source : 85be5dca7ac79d4631d090cafc3f01994a4223b0
Summary:
The reason for this ticket was that it was not immediately obvious for
Sync users that deleting logins on this device may affect all logins stored in
user's Sync account. So it was possible that users could unintentionally loose
all their login data.
While we should still offer the option to remove login data, even to Sync users,
we will explicitly inform them that deleting logins can affect all their
synced logins.
Also refactored the code to minimize duplicated code.
Depends on D16026
Reviewers: JanH, #geckoview-reviewers
Reviewed By: JanH
Subscribers: reviewbot, flod
Bug #: 1473470
Differential Revision: https://phabricator.services.mozilla.com/D16027
--HG--
extra : rebase_source : a0e83ce91e7d217c6b46fa81472eb5f54c92420d
extra : histedit_source : b9d9435857c04a73d960275409fd65cf1725edcb
This eliminates one potential source of crashes from passing bad orientation
values to onOrientationChange.
Differential Revision: https://phabricator.services.mozilla.com/D16207
--HG--
extra : moz-landing-system : lando
The arguably most interesting bit of state of BrowserApp/GeckoApp, namely the
currently open tabs, are living partly in Gecko and partly in the Tabs
manager singleton, the lifetimes of both of which are tied to the lifetime of
the app process.
If the whole process has been killed, things are simple: Neither the Tabs
manager nor Gecko know anything about any tabs and we simply restore them
through the session store if enabled.
If GeckoApp is however being restored into an app process in which it had
already executed earlier on, meaning that we have some open tabs, it relies on
the savedInstanceState in order to correctly reconnect its GeckoView instance
with the correct previous GeckoSession.
We can however end up in a state where we don't have a savedInstanceState (e.g.
because the user swiped away the BrowserApp activity in the task switcher), but
the app process keeps running throughout (if another activity of ours is still
present in the task switcher, e.g. a custom tab, or else if a service is active,
then standard Android keeps the process running even if the user swipes away an
activity).
In that case, if GeckoApp is subsequently recreated, the Android UI sees all the
Android-side tabs in the Tabs manager, and Gecko in fact still has the Window
open that is containing all those tabs, but without the savedInstanceState
GeckoApp doesn't know anything about that Window and proceeds to open a fresh
session instead.
This means that all previous tabs will appear white and unresponsive, while
freshly opened tabs will load, but they won't be correctly saved in the session
store, their context menu isn't working, etc., because we're not really
expecting to handle multiple Gecko-side Windows.
To fix this, we disable automatic state-saving for GeckoApp's GeckoView instance
and instead do it manually, so we can keep another reference to the saved state
in GeckoApplication, and therefore are able to retrieve it from there for as
long as the app process keeps running.
Differential Revision: https://phabricator.services.mozilla.com/D16393
--HG--
extra : moz-landing-system : lando
Needs to be explicitly declared in case we start targeting Android P.
It's unclear to what extent this is really required when *not* using Android's
network stack directly, but at least with Firefox, some things definitively use
it, e.g. favicons. As we're a browser, we need to allow access to arbitrary
pages, so just generally white-list it.
Differential Revision: https://phabricator.services.mozilla.com/D16408
--HG--
extra : moz-landing-system : lando
For simplicity's sake, for now we keep storing only one scroll position per
history entry (bug 1499210), so if we have to choose between the layout and the
visual viewport, the latter is a vastly better choice, as it more accurately
represents the scroll position as perceived by the user, especially when the
page has been pinch-zoomed.
This also means that instead of the normal scroll events, the session store now
has to listen for the corresponding events specific to the visual viewport.
We also extend the scroll position test to check that the scroll position isn't
just properly saved, but also actually properly restored in practice as well.
We only add this test now instead of already adding it beforehand like we did
with the rest of the test
- to avoid having to temporarily extend the checkScroll() helper function to
deal with todo()/todo_is etc.
- because getting that part of the test to complete without timing out (which
would be one of its natural failure modes, because the expected events would
be missing) would require faking even more scroll events
- because we already have the todo() tests that are telling us the we didn't
*store* any scroll position in the first place, so there's no point in trying
to actually restore anything
For the GeckoView saveAndRestoreState test, we now spin the event loop once
before setting the scroll position in order to give APZ opportunity to settle
down after the initial page load.
Differential Revision: https://phabricator.services.mozilla.com/D15690
--HG--
extra : moz-landing-system : lando
The existing tests didn't catch this problem, because calling scrollTo(), which
is both what
a) the session store and session history itself are currently using to set the
scroll position to be restored, as well as
b) how the existing session store test is setting the page up to be scrolled
ready for testing
forces both the layout and visual viewport positions to the respective
coordinates, even if the same configuration of visual and layout viewport
offsets could never be achieved through manual scrolling (i.e. bug 1516056).
This then triggers all the expected events and makes it so that reading the
scroll position through the layout viewport returns the expected values, which
is why the existing tests never noticed that something is off.
Therefore, we introduce a test here that has a page where the layout viewport
can never scroll (at least horizontally) and where we simulate scrolling by
actually inputting fake touch events instead of simply calling scrollTo().
This will result in only the visual viewport scrolling, ensuring that we can
properly test the new expected behaviour of the session store and session
history.
Because layout and visual viewport scroll positions aren't necessarily updated
at exactly the same time and the session store is currently still relying on the
conventional "scroll" events (relating to the layout viewport), which means the
tests have to rely on the same events, too, we don't yet switch all session
store tests to generally verify the current scroll position of the page using
the visual viewport, and temporarily make this only opt-in via the corresponding
helper function in head_scroll.js.
I know that the proper way to reference "foreign" files in text manifests is to
use !/absolute/path/to/file/helper.js, but as one of the files originally comes
from a chrome mochitest and the other one (apz_test_utils.js) doesn't and this
test itself is a chrome mochitest, this was the best way I found to get both
files copied into the correct directory on the test device so the test could
access them.
Differential Revision: https://phabricator.services.mozilla.com/D15685
--HG--
extra : moz-landing-system : lando
... so it can be shared across multiple test files.
Also make slightly more use of modern JS features for destructuring objects etc.
Differential Revision: https://phabricator.services.mozilla.com/D15684
--HG--
extra : moz-landing-system : lando
Given the usage example of pull-to-refresh in bug 1371796, downstream consumers
will probably more interested in the true visible scroll position of the user
within the page, i.e. the visual viewport.
Listening for *visual* viewport events will also definitively be required to
get the saveAndRestoreState GeckoView test properly working once we switch
Gecko's session store helper function to use the *visual* viewport scroll
position.
Differential Revision: https://phabricator.services.mozilla.com/D15682
--HG--
extra : moz-landing-system : lando
In order to make the history easier to navigate, this changeset includes the
modifications required to make <xul:browser> actually work as a Custom Element,
and switches the app to use it instead of the XBL browser.
Differential Revision: https://phabricator.services.mozilla.com/D14911
--HG--
extra : moz-landing-system : lando
Part 1 - Add methods for each setting in `GeckoSessionSettings`.
Migrate existing code to use these new methods instead of the exisiting get/set<DataType>(Key, Value) methods.
Part 2 - Make old methods and fields for get/set<DataType> in `GeckoSessionSettings` private.
Part 3 - Migrate existing code to use these new methods instead of the exisiting get/set<DataType>(Key, Value) methods.
Part 4 - Add Builder to `GeckoSessionSettings` to handle setting of init only fields.
* Make setters for init only fields protected.
* Remove tests that ensure that init only fields throw an error when set on the fly as this is no longer possible.
* Update tests to use builder when init-ing settings.
* Update API doc to reflect new public API.
Part 5 - Update `CHANGELOG.md`.
Part 6 - Update `geckoview_example` to use new methods.
Part 7 - Fetch `CHROME_URI` key when calling `getChromeUri` rather than incorrect `USER_AGENT_OVERRIDE`
Differential Revision: https://phabricator.services.mozilla.com/D15651
--HG--
extra : moz-landing-system : lando
Refreshing account (triggered by signing in) can cause a NullPointerException after quickly signing out.
This defect consists in bad sync between the signing in state and signing out state.
Differential Revision: https://phabricator.services.mozilla.com/D14269
--HG--
extra : moz-landing-system : lando
Let SessionStoreUtils be a WebIDL namespace, rather than a XPCOM service
Differential Revision: https://phabricator.services.mozilla.com/D9776
--HG--
rename : toolkit/components/sessionstore/nsISessionStoreUtils.idl => dom/chrome-webidl/SessionStoreUtils.webidl
rename : toolkit/components/sessionstore/nsSessionStoreUtils.cpp => toolkit/components/sessionstore/SessionStoreUtils.cpp
extra : moz-landing-system : lando
We want to remove recently closed tabs from the session store when they get re-
stored again, and for that we need something to uniquely identify them.
As tab IDs are unique per session only, this means that the tab IDs of recently
closed tabs resurrected from the previous session could conflict with tabs that
have been freshly opened in the current session.
E.g. tab 2 has been closed in a previous session and is now part of the session
store's closed tab list. In the current session, a number of tabs are opened
again and then what is now the *current* tab 2 is closed as well. The result
would be that the session store now has two closed tabs with a tab ID of 2.
To avoid that scenario, all recently closed tabs are renumbered with an ID in
the negative range at the start of the session. Therefore all tabs originally
opened in the current session will have a tab ID >= 0, while all recently closed
tabs coming directly from a previous session will have a negative tab ID, < -1.
(-1 itself remains the sentinel value for an invalid tab ID).
Differential Revision: https://phabricator.services.mozilla.com/D15331
--HG--
extra : source : 971ebdae024e188a913d2eda452a7761b4b38d1b
extra : histedit_source : b04ac438d2d7325d35e300946fcdb2a385b1598c
We want to remove recently closed tabs from the list that have been restored
again. At the moment this only works if the tab data never leaves Gecko, because
in undoCloseTab(), the session store determines the tab data to be removed from
its closed tab collection by checking for equality with the tab data that was
passed as an argument to undoCloseTab().
So a tab restored through the "Undo" snackbar will be removed from the "Recently
closed" list, but a tab restored from the History home panel won't, because in
the latter case the tab data will have been serialised and deserialised while
travelling back and forth between Gecko and the Android UI.
Hence we're going to switch the system to identify tabs through their tab ID
instead.
If automatic session restoring is turned off, the "Recently closed" home panel
also displays all tabs that were open in the previous session. Those tabs aren't
coming directly from the session store; instead the Android UI reads them
directly from the corresponding file on disk. Therefore, when restoring such a
tab we need to make sure that the session store won't attempt to find and remove
that tab from its own list of recently closed tabs.
To that effect, we therefore simply drop the "tabId" when parsing the "last
session" file from disk.
Differential Revision: https://phabricator.services.mozilla.com/D15330
--HG--
extra : source : cedb3b5d62a6019a1176f2196848d7bb43c74e9d
extra : histedit_source : 88e2c1f549c98d0cf9adeaf91891f3de61fca499
Nobody within mobile or toolkit is currently using it.
Differential Revision: https://phabricator.services.mozilla.com/D15328
--HG--
extra : source : 531c402060ecc2bc3d1119ecaf3b49b29e03e3cc
extra : histedit_source : 0e86b12909c5f76605304a0a0ff4088031a7b8b9
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
On versions prior to Android N (24), initializing the WifiManager via Context#getSystemService can cause a memory leak if the context is not the application context.
Differential Revision: https://phabricator.services.mozilla.com/D14721
--HG--
extra : moz-landing-system : lando
This is because these persmissions are the responsibility of the embedding app to request,not GeckoView's.
Differential Revision: https://phabricator.services.mozilla.com/D14722
--HG--
extra : moz-landing-system : lando
The AOSP ExternalStorageProvider always creates document IDs of the form
"storage device ID" + ':' + "document path", where the storage device ID will
be "primary" for the primary emulated storage and the file system UUID for
everything else.
Assuming that OEMs won't customise this behaviour, the main problem that needs
to be handled is how to turn the file system UUID back into a file system path.
Differential Revision: https://phabricator.services.mozilla.com/D15259
--HG--
extra : moz-landing-system : lando
Because getOriginalFilePathFromUri() doesn't use framework methods newer than
Kitkat, instead of a generic @SuppressLint("NewAPI") it would be better to use
@TargetApi(19), so you still get warned if you start using framework methods
more recent than API19.
However because the isKitkat helper variable is only used in one place, in the
end we simply replace it with a direct Build.VERSION.SDK_INT check, so that we
don't have to use any special handling for the linter.
Differential Revision: https://phabricator.services.mozilla.com/D15258
--HG--
extra : moz-landing-system : lando
Instead, getOriginalFilePathFromUri() will simply *always* return null if it
cannot divine the original file path, and consequently resolveContentUri() will
then always fall back to the temp file method if getOriginalFilePathFromUri()
returns null.
Differential Revision: https://phabricator.services.mozilla.com/D15257
--HG--
extra : moz-landing-system : lando
All of the current usage can survive a timeout, and we'd rather
that than a deadlock. Future code that does want to risk a
deadlock can call `GeckoThread.waitOnGeckoForever` instead.
Differential Revision: https://phabricator.services.mozilla.com/D14560
--HG--
extra : moz-landing-system : lando
Audio/video related context menu entries are already doing this as far as I can
tell.
Differential Revision: https://phabricator.services.mozilla.com/D15382
--HG--
extra : moz-landing-system : lando
Desktop does this when copying link URLs and sharing is just effectively just
another form of copying.
For completeness, we also apply this when "viewing" the source of images (which
just displays the image itself anyway).
No special handling is required for other media elements (audio/video), because
looking at those in view-source mode does display the raw file contents and
thus none of the media-specific context menu entries will show up.
Differential Revision: https://phabricator.services.mozilla.com/D15381
--HG--
extra : moz-landing-system : lando
The `privateSession` key would normally allow persisting the Private Browsing
session across OOMs in Activity's Bundle.
We need to do that to avoid storing private, sensible data on disk like we do
with the normal browsing session.
In some cases `privateSession` would contain a lot of data which, along with
other possible concurrent transactions could overflow Binder's buffer which has
a limited fixed size, currently 1Mb.
To avoid this, we will drop `privateSession` from the Bundle if the resulting
size is greater than a _speculative_ size of 300KBs which would mean that in
the case of an OOM all Private Browsing state would be lost.
Bug 1515592 is filed to investigate for a better solution.
Differential Revision: https://phabricator.services.mozilla.com/D15067
--HG--
extra : moz-landing-system : lando
In Bug 1506601 we started specifying a version number which made the javadoc
jar artifact name change
from `geckoview-javadoc.jar` to `geckoview-<version>-javadoc.jar`
where `<version>` is the current GeckoView version. This is a good change but it
broke our javadoc publishing code which doesn't know about the version code in
`//taskcluster/ci/build/android-stuff.yml`.
To make that work we add a new task `copyJavadocJar${variantName}` which copies
the jar to the expected location.
Depends on D15128
Differential Revision: https://phabricator.services.mozilla.com/D15129
--HG--
extra : moz-landing-system : lando
This was fallout from Bug 1509573. That ticket pushed the Android APKs step
into the export tier, where it is required; but since most things in export are
only required for compilation, the target is not itself built by default, and
in particular, not during an artifact build. That's not right; this fixes it.
Differential Revision: https://phabricator.services.mozilla.com/D15002
--HG--
extra : moz-landing-system : lando
This moves the CHANGELOG.md file to a /doc-files folder that gets picked up by
javadoc.
Our javadoc files are hosted on a github.io page which will render the markdown
file with the geckoview profile.
Depends on D13883
Differential Revision: https://phabricator.services.mozilla.com/D14786
--HG--
rename : mobile/android/geckoview/CHANGELOG.md => mobile/android/geckoview/src/main/java/org/mozilla/geckoview/doc-files/CHANGELOG.md
extra : moz-landing-system : lando
This test formerly used a bootstrapped extension. Converting it to a
webextension is straightforward, except for the fact that webextensions
are started asynchronously, so the test has to wait for a message from
the addon instead of just assuming it is started synchronously during
distribution handling.
Differential Revision: https://phabricator.services.mozilla.com/D13635
--HG--
extra : moz-landing-system : lando
This splits the two stage-package invocations (which are rather slow)
between Fennec and GeckoView, hopefully speeding local GV development
up a little (in the IDE).
The stage-package invocations depend on |mach build faster|, because
the omnijar contents might need to be updated.
In addition, we feed the packaged libs (and asset libs) through.
Differential Revision: https://phabricator.services.mozilla.com/D12799
--HG--
extra : moz-landing-system : lando
This is just an awkward feature of the FasterMake build system:
without a direct consumer, GENERATED_FILES aren't handled. We
"consume" them into a dummy directory that isn't packaged. Sadly, the
FasterMake generic rule doesn't handle relative directories smoothly,
so we have to special case that too.
Differential Revision: https://phabricator.services.mozilla.com/D12796
--HG--
extra : moz-landing-system : lando
This uses |mach build mobile/android/base/...| rather than a custom
target, reducing Make magic and making it a little easier to reason
about the Gradle build. This is somewhat rearranging deckchairs, but
the more that gets out of Make and into moz.build, the simpler our
lives become.
The shared `onlyIf` Gradle guard will be used to make it very clear
when certain tasks are being skipped, as we move details about Gecko
binaries to depend on the Gradle task execution graph.
I also took the opportunity to improve the task logging.
Differential Revision: https://phabricator.services.mozilla.com/D12798
--HG--
extra : moz-landing-system : lando
This was always an accident of history: we forced export tier without
avoiding it in the libs tier.
Differential Revision: https://phabricator.services.mozilla.com/D14893
--HG--
extra : moz-landing-system : lando
Summary:
Add autofill hint test if using Android 8+.
Depends on D12881
Reviewers: droeh
Reviewed By: droeh
Bug #: 1497682
Differential Revision: https://phabricator.services.mozilla.com/D12882
--HG--
extra : rebase_source : c4458b62d48434fe9d19f8ded04f2bc2666647ff
extra : histedit_source : 5ff01309b49965ff008e431059368ca0f05d56e6
Summary:
LastPass will fill password to all input elements which InputType is
TYPE_CALSS_TEXT and TYPE_TEXT_VARIATION_WEB_EDIT_TEXT and has no AutofillHint.
And it will fill username when InputType and AutofillHint is nothing in
<input type="text">.
Actually, current implementation of GeckoView sets InputType only for
<input type="text">, so LastPass fills password to all <input type="text">
So as workaround, we should set InputType and AutofillHint when input element
presumes username fields.
Depends on D12880
Reviewers: droeh
Reviewed By: droeh
Bug #: 1497682
Differential Revision: https://phabricator.services.mozilla.com/D12881
--HG--
extra : rebase_source : b5ab3deadf0dd67bbdb1aa7e7656fe677c6670c4
This simplifies things all around, and gets rid of one more unnecessary
component registration.
--HG--
rename : toolkit/components/extensions/extension-process-script.js => toolkit/components/extensions/ExtensionProcessScript.jsm
extra : rebase_source : 7ceb6ada0730f8241bbd5ddbd889a320da22b1b1
This makes it so that apilints lints with "GV" codes are enforced and will fail
the build.
Depends on D13882
Differential Revision: https://phabricator.services.mozilla.com/D13883
--HG--
extra : moz-landing-system : lando
Child processes cannot access textures allocated in the parent process,
which is needed by the compositor to render video elements efficiently.
Unfortunately, Android doesn't expose Sufrace buffers (sharable across
processes) in the SDK/NDK as other platforms, so we need to generate
extra texture/surface in the child process and update texture images
through the surface, which is passed to the parent process for the remote
texture to copy its contents into.
Differential Revision: https://phabricator.services.mozilla.com/D11939
--HG--
rename : mobile/android/geckoview/src/main/aidl/org/mozilla/gecko/gfx/ISurfaceAllocator.aidl => mobile/android/geckoview/src/main/aidl/org/mozilla/gecko/gfx/SyncConfig.aidl
extra : moz-landing-system : lando
Inside the tests from testMediaControl audio focus is not immediately checked
as for the tests from testAudioFocus but nonetheless we should make sure
AudioFocusAgent is initialized before proceeding with the media tests.
Depends on D14417
Differential Revision: https://phabricator.services.mozilla.com/D14418
--HG--
extra : moz-landing-system : lando
There is a small race between actually starting the test after Gecko:Ready and
having the AudioFocusAgent that the tests depend on initialized, which is also
done after Gecko:Ready.
To avoid this situation we will wait for Gecko:Ready and then for
AudioFocusAgent to complete it's initialization.
Differential Revision: https://phabricator.services.mozilla.com/D14417
--HG--
extra : moz-landing-system : lando
Looking at Crash Stats, the most common causes of OOMs involving the RecentTabs-
Adapter happen while reading the previous session store file into memory for
parsing, respectively while stringifying the parsed data back into a flat String
for further storage.
In the former case, we give up completely, because there's nothing we can do
short of switching to a streaming JSON parser (which is out of scope for this
bug), while in the latter case, we only skip the affected tab in the hope that
at least some tabs might be small enough to not cause an OOM.
Differential Revision: https://phabricator.services.mozilla.com/D12963
--HG--
extra : moz-landing-system : lando
We just treat this like a defective session store file and first fall back to
the backup (although if the OOM is caused by a too-large file, it is likely that
the backup will be too large as well) and then turn off session restoring
completely.
We don't plug those failures into the session restore telemetry, though, because
that is supposed to only cover truly defective files.
Differential Revision: https://phabricator.services.mozilla.com/D12962
--HG--
extra : moz-landing-system : lando
This patch moves all UA Widget calls to helper functions in Element.cpp. The helper function AttachAndSetUAShadowRoot sets the shadow root in a runnable, so that it is in the same order of NotifyUAWidget* runnables.
Differential Revision: https://phabricator.services.mozilla.com/D13479
--HG--
extra : moz-landing-system : lando
This adds a task to each project called `downloadDependencies`. This task will
go through each configuration and resolve every dependency so that the gradle
cache contains a copy of every file needed for building and running tests. This
is intended to be used together with our nexus oss database but it can be used
locally too.
Note: `downloadDependencies` does not download dependencies added a runtime,
e.g. by plugins like apilint, checkstyle, findbugs... so we still need to run
those tasks to collect their dependencies.
Depends on D14516
Differential Revision: https://phabricator.services.mozilla.com/D14622
--HG--
extra : moz-landing-system : lando
