This allows us to allocate an Android SurfaceTexture in the compositor process as well
as an accompanying Surface. We can then transfer the Surface back to the content process
via binder, where it can be used for things like WebGL and video decoding.
Each SurfaceTexture/Surface pair has a unique handle. We use this handle in
layer transactions to locate the SurfaceTexture for a given Surface and composite it
appropriately.
MozReview-Commit-ID: 68VSbXdfsMH
GeckoAppShell.scheduleRestart was called from XPCOM toolkit when we
needed to restart after the Gecko thread exits. But because we made the
"Gecko:Exited" event contain a "restart" flag, we can handle that
entirely in Java now, so we don't need to call
GeckoAppShell.scheduleRestart anymore.
Move the code that actually performs shutdown from BrowserApp to
GeckoApplication, so we can shutdown even without an active BrowserApp.
From inside GeckoApp/BrowserApp, all shutdown now go through
finishAndShutdown(), which destroys the Activity before shutting down.
Add test for handling the cases, media with silent audio track and media without audio track.
MozReview-Commit-ID: 5vV9EjIjHQt
--HG--
extra : rebase_source : 37fccc055479a40fd802107ccdc45d11d11c1852
When a non-restartless add-on is (un)installed or updated, we show a doorhanger prompting the user to restart. Currently, the doorhanger's title is using the default logic for choosing its title, that is using the base domain of the tab the doorhanger is being displayed on.
By chance, when the doorhanger is triggered from about:addons there is no domain to display, so the doorhanger is just displaying the restart notification. If however an add-on is automatically updated while the user is browsing, then the restart prompt will show the domain of the currently open tab in conjunction with the restart message. This can be confusing for the user, as it looks like it was in fact the current page that triggered the restart prompt.
Therefore, we change this behaviour and just show a generic "Add-ons" as title for this case.
MozReview-Commit-ID: 3pMwSiLul99
--HG--
extra : rebase_source : 3c11fe19c5cef42226a849b78d554fa846114bfa
At the moment, our crash loop counter that turns off session restoring when multiple crashes happen in a row is reset only after a successful background-foreground cycle.
Since its purpose is to break out of startup crash loops caused by the currently loaded tab that is automatically loaded after starting the app, it makes sense to also reset it if we didn't crash soon after starting up. Otherwise, if the user remains within Firefox, another crash long after starting would still count towards the crash loop counter.
Desktop already employs a similar logic for deciding whether to automatically enable safe mode or not after a crash. Therefore, we use the same amount of time (30 s) after starting Gecko for resetting the counter.
We also take the opportunity to make our logic a bit more conservative and only turn off session restoring after two successive crashes in a row (desktop uses 3 by default).
MozReview-Commit-ID: CQDutkDgmfc
--HG--
extra : rebase_source : e3100394772bcebb64610dcadfd77676119e1de1
Those settings need to be stored in our shared preferences since they're needed before Gecko is available, however in order to allow them to be easily configured, we also expose them in about:config and sync them to the shared prefs via a change listener.
This however means that changes in the *default* value of those prefs won't be picked up. Therefore we now simply unconditionally copy the setting state into the shared preferences on startup and omit the change listener instead, as they're exposed in about:config only and there is in fact no pressing need for changes there to immediately take effect.
MozReview-Commit-ID: 7c950F1nkdj
--HG--
extra : rebase_source : 4be6e5124294a71b5d214b9ab10ada4e88aee3bb
I observe that sometime it takes longer time for the UI notification changed in
try sever, and it cause the intermittent fail.
Therefore, I would like to increase a little bit time for waiting UI changed.
MozReview-Commit-ID: BnsZq3DObFa
--HG--
extra : rebase_source : 034f38799a2f9722f23bb0a2a139047d21508729
Use notification id to check whether the notification is correct is more stable than just checking the
number of system notification.
MozReview-Commit-ID: BVYdMrBsSLR
--HG--
extra : rebase_source : 9be3ca9a854c25a61bf233a24e7ed7745efacb1a
Since the robocop tests would run on super slow emulator on try, and then we
can't wait the tab's audible state change within the MAX_WAIT_MS time. It might
need more time.
So, we should check the media has been started by waiting the "Tab:MediaPlaybackChange"
event, and then to check other tab's attribute.
In addition, move the tab attribute checking independently into new functions,
so that we would clearly see that we have four things need to check in function
checkIfMediaPlayingSuccess().
- tab's media playing state
- media notification UI
- tab's audio playing state
- audio focus state
MozReview-Commit-ID: 8S0Ems23iPX
--HG--
extra : rebase_source : 9bbe525ba1dcdf8415d034ced39d9a9a4836f1e9
To make sure these functions can be used in robocop test.
MozReview-Commit-ID: KPAKOrg5Ows
--HG--
extra : rebase_source : 8ef6dd7c14e8dc0d3219aed0901793a17f945372
Add check for media notification's small icon, title and content text.
MozReview-Commit-ID: AOhag8gQVqs
--HG--
extra : rebase_source : 8ad1c7fa0e7796a0d873fba432c646846a0742d3
It's easy to know what test tasks we'll run in this test.
MozReview-Commit-ID: DdtFp4pOXlC
--HG--
extra : rebase_source : 5615d2c1169ee0f59c95ab21d3e5e2fd26c99a33
Create new test class for reducing the redundant code and can provide more
flexibility for adding new related test in the future.
MozReview-Commit-ID: 2f3O8vfHo12
--HG--
extra : rebase_source : 2b0d7a337c87afd8e844f435f7e605b881f1aa1b
Notify observer might cause the method (notifyStoppedPlaying) is called by C++ side,
and we should change our internal state before calling the method.
MozReview-Commit-ID: 5xNXhGmAIrR
--HG--
extra : rebase_source : 362f921e68d795f568816b1c0a23c0f50c5d0790
When starting up, ideally we want to only load the foreground tab, with all other tabs being created as delay-loaded "zombie" tabs that occupy minimal resources. To that extent, when restoring the previous session we need to know whether we're planning to open an additional, external tab for a URL received through the launch intent later on. If we do, we don't want to select any tab while restoring the previous session, as that selection is going to be overridden by the external tab anyway. Not selecting a tab from the previous session at this stage means that it can remain as a delay-loaded tab until it is eventually selected by the user.
MozReview-Commit-ID: 1lWnOx0ZuNl
--HG--
extra : rebase_source : 03a286ec3e1c66856d2ffb526cd4277c89b29594
Iris Hsiao
Wes Kocher
Jim Chen
James Willcox
James Cheng
Alastor Wu
Jan Henning
Ted Mielczarek
Jing-wei Wu
Tom Klein
Mark Banner
Dale Harvey
Carsten "Tomcat" Book
Gijs Kruitbosch