CLOSED TREE
--HG--
extra : amend_source : 84120d6bacb5d72a9fbe41e4c3b405d63825da7c
extra : histedit_source : 8320c2193761b745f10850055ee74a3c9ac73615%2Cfbc2a28d8c5004a53305ef858ca5aea4245691e0
Add a `window` parameter to all Prompt.jsm usages, so the prompt will
appear in the correct window. This includes HelperAppDialog.js, which
was preventing the download chooser dialog from appearing in a custom
tab window.
The patch also moves `getActiveDispatcher` from GeckoViewPermission to
GeckoViewUtils, and makes several improvements to `getChromeWindow` and
`getDispatcherForWindow`. Prompt.jsm now uses the active
WindowDispatcher in the fallback scenario where we don't have a window.
MozReview-Commit-ID: KpAFMCZzQZp
Icons apparently doesn't fade images, however, so it looks bad. Also, we try to
request the image each time we bind, so scrolling up and down will create
additional pop-in, which also sucks.
MozReview-Commit-ID: 246pokTMFl7
--HG--
extra : rebase_source : 8cb2750225d2e0331b1cfe25e02c766dd631e565
Now that we have a Docker image with newer library versions on it, we
can move our builds over. The new images differ from the old
CentOS-based images in two important ways, though:
1) The system compilers in the new image are new enough to be used as
host compilers; additionally, our CentOS-built GCC compilers will not
work. We need to change the Android mozconfigs to reflect that. We
also need to change the Android tasks to not depend on the GCC
toolchain builds.
2) In a similar fashion, we can use the system JDK; we no longer need to
use the JDK from the Android NDK, which we had packaged up via the
Android dependencies task.
Both of these changes come with caveats: our l10n repack jobs continue
to run on the CentOS-based images; l10n repacks have not been completely
converted to Taskcluster. So we need to:
1) Retain the use of our custom GCC toolchain for HOST_CC/HOST_CXX on
the CentOS-based images.
2) Retain the JDK packages in the tooltool manifests, and referencing
them when we build on the CentOS-based images.
Update the host jsshell, which is used for minifying Fennec JS code, to
the one from the 56 release, so minification works again.
MozReview-Commit-ID: K87XQrAbC9p
--HG--
extra : rebase_source : 9ae4aad02ca11bdde0d2da9f0bb98fb5e83769d1
I believe this doesn't affect this bug because I think the ViewHolders are
recreated on rotation but for any other type of change, only bind will be
called so for correctness, we should update the size in bind.
MozReview-Commit-ID: 3ojO4TF89i4
--HG--
extra : rebase_source : 6376aca2f6858261ca913fa0f613cbdb9be2b4bf
In this sense, it acts as a refresh function, binding all of our UI state at
the same time, helping to prevent bugs where the UI gets out of sync.
For example, this fixes this bug because now the tileSize gets updated when we
swap the cursor, not just when we the page is initially constructed.
MozReview-Commit-ID: 7V2gFyiOJ1R
--HG--
extra : rebase_source : 4e0f35f391d8174f02930a0a39a8981bc048c8ee
This will help prevent the cache from going out of date.
MozReview-Commit-ID: GdUXF0oOSiK
--HG--
extra : rebase_source : f6c0e40c150ec1419b5fecb5ef6b8e5f8b534373
Since it's a constant, there's no reason to keep passing it around everywhere.
Also, the code that relied on it being a dynamic value is probably broken so
there's no reason to continue passing it around.
That being said, there is bug 1397854, which would have TopSites be 4 rows with
no pages, but this code is quite messy so I think it'd be worth trying to
refactor this code further before trying to implement that.
MozReview-Commit-ID: IoMNHVt67c4
--HG--
extra : rebase_source : 7ea79634c5e03fdc17a9df977f231f48244c3ca3
The TopSitesPage should really own details about the appearance of top sites.
MozReview-Commit-ID: LPfHGcUTv00
--HG--
extra : rebase_source : 4a58a064889664fb4d220f53c1af90ad02e85d5c
Use ActionBarHandler in BrowserCLH.js instead of browser.js, so it can
handle text selection for all windows. Also update ActionBarHandler to
reflect the new usage and to support multiple windows.
MozReview-Commit-ID: G8sKu2XyAAG
Add `GeckoViewUtils.registerLazyWindowEventListener` that, similar to
`addLazyEventListener`, will register a lazy event listener with the
per-window EventDispatcher.
MozReview-Commit-ID: AX3EQGpmdw
Move the "Share:Text" event listener from GeckoApp to GeckoApplication,
so ActionBarHandler.js can use it for the Share action from any window.
MozReview-Commit-ID: 8w1llJy4pwy
Make TextSelection implementations not depend on GeckoApp. Instead, make
them use GeckoView's EventDispatcher directly for communicating with
Gecko.
MozReview-Commit-ID: EygAt3D9HMI
Use event callbacks instead of separate events to deliver
FormAssistPopup replies back to FormAssistant. This lets us better
handle having multiple FormAssistPopup instances across Fennec, custom
tabs, and PWAs.
FormAssistant._currentInputElement is removed because it does not allow
us to have multiple concurrent popups. Instead, we track the current
element through the event callback closure.
FormAssistant._currentInputValue is also removed for similar reasons,
and I don't think it was really necessary.
MozReview-Commit-ID: DdeMBGCxDou
To support FormAssistPopup in custom tabs, we need to move the
FormAssitant object out of browser.js and into its own separate file.
BrowserCLH.h in turn loads FormAssistant.js when necessary.
MozReview-Commit-ID: 7CFQ9R16P4J
Move the form fill event listeners out of browser.js and into
BrowserCLH.js, and update them to support chrome windows, so we can
handle form fill events for Fennec, custom tabs, and PWAs.
MozReview-Commit-ID: Fb5gWmGvxfE
Use the BrowserCLH for PromptService startup, to consolidate startup
handling code and also to delay loading PromptService.
MozReview-Commit-ID: 25UgVH7wrrs
Move `addLazyGetter` and `addLazyEventListener` utility functions from
GeckoViewStartup.js into GeckoViewUtils.jsm, so they can be used for
both Fennec and standalone GeckoView.
Also switch to "chrome-document-loaded" for loading
DownloadNotifications because that's later in the startup sequence.
MozReview-Commit-ID: 1caMtufkHGR
The mechanics implemented here involve listening for extension updates that
require new permissions, notifying the user with icons attached to the
top level Add-ons menu and to the individual item in about:addons, and
then showing the permissions dialog when the user asks to update.
The basic plumbing is mostly in ExtensionPermissions.js, this also
required a fair amount of change to aboutAddons to accomodate new UI
elements, and to handle updates gracefully.
MozReview-Commit-ID: Jkgc3OVYtnc
--HG--
extra : rebase_source : 5df3e12df8c422285fbc25c459dc420b395fa824
Sometimes Robocop is confused when are multiple `R.id.menu` UI components shown on screen,
one is the menu button on toolbar and otehrs are context menus on Activity Stream.
To access the menu on toolbar, a simple fix is access toolbar first and use it to find its child.
MozReview-Commit-ID: Jw4sTLeR3li
--HG--
extra : rebase_source : 337c3df3ffd36a4d26547b994aba3ce7647bafc8
I don't scale the pin size/margins based on the dynamic tile size. This could
mean we get into situations where the pin crowds out the top site tile but I
don't know if this would happen in practice.
MozReview-Commit-ID: Ct8EP3dPr6N
--HG--
extra : rebase_source : b527cff1faf5a565d1cf309ce3063b8d23553150
GeckoMenu always create view from MenuItemDefault. Now lets adding a
new type for MenuItem which will display a Drawable in right side.
MozReview-Commit-ID: F7zVDze0RaP
--HG--
extra : rebase_source : c913ef385aaf99c948edb252136c2b7f39526730
extra : intermediate-source : 2c098c90a58faee8b928eb1cec5cb841897c57e2
extra : source : b107e0b122445393a804116d763e2f13da6b6036
In Android, "privacy.trackingprotection.state" is not a "real" pref name, but it's used in the setting menu and browser.js.
"privacy.trackingprotection.state" and "privacy.trackingprotection.pbmode.enabled"(deleted) in Android is init in Helper.getPrefs and passed to browser.js when changed.
The real pref for tacking protection are two Gecko pref in browser.js. They are:
"privacy.trackingprotection.pbmode.enabled"
"privacy.trackingprotection.enabled"
All prefs in Android are delegated to them. The Android setting UI simply reflects the single source of truth (Gecko pref).
That's the reason why the two Android perfs use android:persistent="false"
MozReview-Commit-ID: 5ehBhtNM2Tx
--HG--
extra : rebase_source : 02ad1f3f778589ce05529f22d7d7bee03e5970e5
add check for external url in onNewIntent, use Tab.addTabs() for no url or about:home
MozReview-Commit-ID: AX5pj52lC8i
--HG--
extra : rebase_source : a72afb060dcdea4678969063ee4568186ea863d6
(by nalexander, from Bug 1375571)
This is follow-up to Bug 1220892, which just forgot to remove these strings.
MozReview-Commit-ID: 2WLa0AC8BZp
--HG--
extra : rebase_source : cc0d4711a0f4d38980a67ed64054cf96b5683a1b
In Android, "privacy.trackingprotection.state" is not a "real" pref name, but it's used in the setting menu and browser.js.
"privacy.trackingprotection.state" and "privacy.trackingprotection.pbmode.enabled"(deleted) in Android is init in Helper.getPrefs and passed to browser.js when changed.
The real pref for tacking protection are two Gecko pref in browser.js. They are:
"privacy.trackingprotection.pbmode.enabled"
"privacy.trackingprotection.enabled"
All prefs in Android are delegated to them. The Android setting UI simply reflects the single source of truth (Gecko pref).
That's the reason why the two Android perfs use android:persistent="false"
MozReview-Commit-ID: 5ehBhtNM2Tx
--HG--
extra : rebase_source : ef38ab9ac20408cbe0a0ad9ccd12c097e2ee6861
Our user-facing builds crash if we manage to slip in some main thread network access by mistake (which is the default Android StrictMode policy since Honeycomb), so our developer builds shouldn't be more forgiving here.
MozReview-Commit-ID: 6bZwwwrSb3q
--HG--
extra : rebase_source : 8f4258de89f141ce6d3b2b141b1e4daa1dc6f6aa
Move the form fill event listeners out of browser.js and into
BrowserCLH.js, and update them to support chrome windows, so we can
handle form fill events for Fennec, custom tabs, and PWAs.
MozReview-Commit-ID: Fb5gWmGvxfE
--HG--
extra : rebase_source : 1ecb7f83bc8022cb3fef1a5ffa9d9d084b837bf4
Use the BrowserCLH for PromptService startup, to consolidate startup
handling code and also to delay loading PromptService.
MozReview-Commit-ID: 25UgVH7wrrs
--HG--
extra : rebase_source : 162ee97db80608caf3c5cd93734764bc87b99c6f
Move `addLazyGetter` and `addLazyEventListener` utility functions from
GeckoViewStartup.js into GeckoViewUtils.jsm, so they can be used for
both Fennec and standalone GeckoView.
Also switch to "chrome-document-loaded" for loading
DownloadNotifications because that's later in the startup sequence.
MozReview-Commit-ID: 1caMtufkHGR
--HG--
extra : rebase_source : eea04495bd96e98a83d4874709f2a88d989ee466
We would like to change the status bar color based on different situation:
- For mobile, the status bar color is
#F7FAFC in normal mode,
#38383D in private mode, and
#272727 in tabs tray page
- For tablet, the status bar color is always #272727
MozReview-Commit-ID: Ala5ZOYJ8Ad
--HG--
extra : rebase_source : f49de0c48ec45b210cea092eb0cdce6f1d9e3d39
Call `onBackPressed()` when `android.R.id.home` is selected to make sure the same click behavior between
HomeAsUpIndicator and back button.
MozReview-Commit-ID: 3tTKtbDTugg
--HG--
extra : rebase_source : 5b59a4c23efb30bade427a28242885480cbedf77
Due to how we access our prefs files (read: all over the place), the idea here is to perform the migration whenever
some component actually attempts to get the prefs. This guarantees that every consumer of prefs will receive the
correct version, and we won't accidentally duplicate our shared prefs either.
I would have preferred to just perform this migration at a set point.
We have a "services upgrade point" - FxAccountUpgradeReceiver - which receives a "package upgraded" intent and kicks
off some async work. Unfortunately, we can't guarantee that its tasks won't overlap with our uses of prefs
(either in the background or foreground code).
MozReview-Commit-ID: AWQ4IY7i32F
--HG--
extra : rebase_source : 7f585e8a71291fb812937b4846ce790a9b332fac
This patch is necessary for the previous changesets to take effect.
MozReview-Commit-ID: 98IemAEgbmi
--HG--
extra : rebase_source : 2609d0168b525b96a4392c15430a7dc85323da59
This is part 1 of the good-enough approach: see the MAX_SCALE_FACTOR comment
as to what we're aiming for. The next changeset will discard any icons that
do not look good being scaled so much.
The MAX_SCALE_FACTOR field is non-private because it's used in the next
changeset.
MozReview-Commit-ID: HGzdQBEuMAy
--HG--
extra : rebase_source : 9ac7ad89e0866a3af89c4086ae59255ebedeb31c
This is the desired behavior but as per comment 8, it breaks a few existing
distributions' titles so we'll display two lines for those distributions in
the upcoming changesets.
MozReview-Commit-ID: CKFbHXbs3HT
--HG--
extra : rebase_source : 90c3a58b05c1a6fcaff56e7524b3d0f6c851e9cd
Move the form fill event listeners out of browser.js and into
BrowserCLH.js, and update them to support chrome windows, so we can
handle form fill events for Fennec, custom tabs, and PWAs.
MozReview-Commit-ID: Fb5gWmGvxfE
--HG--
extra : rebase_source : 8c2d2086e8f612bd823a9b227c9a6b0a0fecee78
Use the BrowserCLH for PromptService startup, to consolidate startup
handling code and also to delay loading PromptService.
MozReview-Commit-ID: 25UgVH7wrrs
--HG--
extra : rebase_source : a47a50f81cbc21ba0aaee714fb1de8099d778450
Move `addLazyGetter` and `addLazyEventListener` utility functions from
GeckoViewStartup.js into GeckoViewUtils.jsm, so they can be used for
both Fennec and standalone GeckoView.
Also switch to "chrome-document-loaded" for loading
DownloadNotifications because that's later in the startup sequence.
MozReview-Commit-ID: 1caMtufkHGR
--HG--
extra : rebase_source : 0c3d92ee2426026d9ec2ad78d77b2c03aa247811
Our shutdown code needs this, so it can wait for sanitising to have actually finished before continuing further.
MozReview-Commit-ID: DGNgFrvYIXV
--HG--
extra : rebase_source : 7ec07f52f2b6dc619042233049f12cc722adb9dd
We don't actually support the find API on Android but we already have permission
strings for other desktop-only APIs under mobile/ (eg bookmarks and history).
Keeping these lists in sync with each other is going to be enough hassle as it
is, lets avoid trying to sync them with what's actually supported on each platform
and just keep the same list of permission strings.
MozReview-Commit-ID: 1A0jhtbMZiG
--HG--
extra : rebase_source : e26bf0f4add077422a8f1a3f1d4c89ce2ac2c3a7
This patch is necessary for the previous changesets to take effect.
MozReview-Commit-ID: 98IemAEgbmi
--HG--
extra : rebase_source : 31b39d30c9b682a9f998add9b47d6743375d0c99
This is part 1 of the good-enough approach: see the MAX_SCALE_FACTOR comment
as to what we're aiming for. The next changeset will discard any icons that
do not look good being scaled so much.
The MAX_SCALE_FACTOR field is non-private because it's used in the next
changeset.
MozReview-Commit-ID: HGzdQBEuMAy
--HG--
extra : rebase_source : 995262e4975a4ebd713cc81f29bc9e84ee2b8d9f
Also use the UA name on all non-official builds, not just Fennec.
MozReview-Commit-ID: 4pKVz1mFnEl
--HG--
extra : rebase_source : d87cc290ad400c386c0a418289aba746eba63c65
I tested this through the unit tests I added.
In theory, we could also validate URLs to make sure they're valid but users
should see 404s if they're not valid so this seems like unnecessary code.
MozReview-Commit-ID: 3XqsMawLabj
--HG--
extra : rebase_source : 7e395dfdb6016f3cb9973e5642c8377928c8fa64
We are going to enable Custom Tabs by default. Now it is still
controlled by SwitchBoard in case of any accident.
MozReview-Commit-ID: JREAhkYzVSu
--HG--
extra : rebase_source : 0e24cb83e39f9d9de66f69e1b98204fea3b04319
Remove related options, just use CustomTabs directly.
MozReview-Commit-ID: DdcMHnsfAU1
--HG--
extra : rebase_source : bc46d5d71d53acadc2cb0415790e9560eeda2c8a
Before we'd recurse instead while fetching multiple batches, overflowing the stack on older devices.
MozReview-Commit-ID: 37BG6zGBdn0
--HG--
extra : rebase_source : fbd6bb43c35baee8da36ea7459615e94d2c9741e
Unfortunately, I can't reproduce so I'm unable to verify this fix works for
sure. However, I verified the behavior of the StreamOverridablePageIconLayout
remained the same after these changes.
As per my bug comments, using the new version of onCreateView may fix this
problem and is "more correct" than this fix but it's speculative and it's too
dangerous to make speculative fixes this close to the 57 merge. Instead, we do
this surefire fix and lose a little correctness.
The onCreateView fix moved to bug 1401779.
MozReview-Commit-ID: DSq9jEgz6gL
--HG--
extra : rebase_source : 3e440fc1c9324f877f3becd342ce83a7daaf8366
libstdc++ support is broken after moving to moz.configure. No one uses this option and NDK will remove GCC, so we should remove this and --with-android-cxx-stl option.
MozReview-Commit-ID: 3mqyHoRCE00
--HG--
extra : rebase_source : 35aa911a69e159e67f624ab5ab9aea8af4c5342f
Before we'd recurse instead while fetching multiple batches, overflowing the stack on older devices.
MozReview-Commit-ID: 37BG6zGBdn0
--HG--
extra : rebase_source : ae54f9cf05229318085331ae30cccdf7f404daaf
1368147 added reading fxa.account.json into the unbundle() codepath for the cases
when the in-memory cache isn't populated. This surfaced a race condition:
pickling of the fxa.account.json file and running unbundle() (as triggered from various
parts of the UI, or othe SyncStatusObservers) will race, and if unbundle wins, it
will attempt to read a yet-to-be-created fxa.account.json file, and crash.
Fixing the race isn't trivial, but we can avoid it by removing the in-memory cache,
thus avoiding having to read the cache key from the pickled file (uid).
In-memory cache was added in response to caching/invalidation issues of set/getUserData,
see Bug 964854 for the history. The current thinking is that those problems are pre-API16,
which hopefully means that we shouldn't encounter them anymore, and thus can remove the
workaround entirely.
MozReview-Commit-ID: AfL2Jq4IlYT
--HG--
extra : rebase_source : 8bcdd1bc084700694d52bce3a2f1ae536b7fe9e1
I don't know the greater context of this code and if this will cause any problems: I'm just following the patterns in Android menus to fix this code.
:aswan is expected to test this patch for me (or provide me steps to test
whether or not it's working correctly).
MozReview-Commit-ID: 9WrqUokwmXT
--HG--
extra : rebase_source : f79940d29d68989efc6ad5e3ccd5ab5590933938
"getEffectiveHost" further down expects the URI to be available - apparently this was broken ever since the original implementation.
MozReview-Commit-ID: C1Q6PBYcvk3
--HG--
extra : rebase_source : 5e71c300261ba9cbaff7e006ce22637c29596680
To avoid mismatches between the Unicode and Punycode versions of a domain, we should normalise the "appOrigin" that can get stored as part of a tab's extra session store data.
To that extent, we move the code that stores the appOrigin into the Tab object's constructor, so we don't have to parse the URL twice.
MozReview-Commit-ID: KFr8CeeOYTe
--HG--
extra : rebase_source : 4494ed02047b33c187143f3789ed663e5022bf35
The URL can end up being user-visible for "Recently closed tabs" (certainly on Android, and also when hovering over an entry on Desktop, at least in the old menu bar), so we should use pretty URLs instead of Punycode.
MozReview-Commit-ID: Kil2ChToYa8
--HG--
extra : rebase_source : 937332a852c6814317cdc58473437e3bc77faf15
Amongst others, this includes some prompts, as well as various progress messages sent to the Java UI.
We also fix getTabWithURL to be able to find tabs regardless of whether the given URL to search is written in Punycode or with Unicode characters.
MozReview-Commit-ID: K7xhgz2IK2h
--HG--
extra : rebase_source : cf8a56ef84be77a6c01d7c926b7eae43a20ca453
This ensures that `intl.locale.os` is always set, even if the system locale changes
while Fennec is in the background.
This commit also restores `Strings.flush()` calls that are necessary to have Fennec's
non-Java UI reflect locale changes.
With this commit, the geolocation popup still doesn't behave correctly: when the
locale system is set to match OS locale, although the pref is set the locale doesn't
change. This applies in two scenarios: on first run (the popup is always English)
and when the locale changes at runtime (the popup uses an earlier OS locale).
Bug 1397925 should complete the fix.
MozReview-Commit-ID: 8zeZuYXFYdy
--HG--
extra : rebase_source : 9da9aae7ed8420faa7567c9db29b1110b3289d9f
Our shutdown code needs this, so it can wait for sanitising to have actually finished before continuing further.
MozReview-Commit-ID: DGNgFrvYIXV
--HG--
extra : rebase_source : 8859ae296af5ad30eca713473ea94a201b98f76b
This has the effect of:
- Aligning the webpage item row with top sites (both 10dp margins)
- Making the icons not cut off
Unfortunately, I don't know why this solved the problem considering the size of
the container did not change. However, the layout_gravity was extraneous and
given all the other work we have to do, I'm fine not researching further.
One thing I noticed is that with layout_gravity, there was an additional
non-colored space in the "Show Layout Bounds" mode with layout_gravity than
there was with out it.
MozReview-Commit-ID: KTZRi1s32gx
--HG--
extra : rebase_source : 3484fc8a0257323c51d805c57979b0904e596483
The util PackageUtil helps to get ResolveInfo of default browser, then
we can use it in CustomTabs menu. If user hasn't set any default
browser, instead we display "..." for browser name.
MozReview-Commit-ID: 6DkFkZ8Ovzq
--HG--
extra : rebase_source : 3ee3d7cccd6e926eafb5edaba6763920979819d6
Originally, the listeners that trigger editing mode and the URL bar's context menu were attached to the BrowserToolbar itself. As this doesn't work properly in conjunction with wrapping the URL TextView into a ScrollView, the listeners were moved onto the TextView itself.
Bug 1389164 reduced the height of the TextView in order to better support lightweight themes with the new toolbar design, which in conjunction with the changes to support the ScrollView has the unfortunate side effect of also reducing the URL bar's hit target area.
Therefore, we increase it back to its old levels by using a TouchDelegate on the ScrollView. Because Android's ScrollView implementation doesn't support TouchDelegates, we have to add the missing bits of logic back in from the default View implementation.
MozReview-Commit-ID: 1nTrrNGvBza
--HG--
extra : rebase_source : 338f3cef0f7e36e7c2968f01170184792a816e9c
If the domain is long enough that it doesn't fully fit within the URL bar, we scroll it such that the end of the domain aligns with the right side of the URL bar, taking any possible fadingEdge effect into account. That way, we always try to show as much of the most important part of the origin as possible.
Chrome uses a similar approach, although their URL bar neither fades nor allows scrolling.
MozReview-Commit-ID: Ep4H4kO4MRH
--HG--
extra : rebase_source : 2ef619e8e756627e8ff55ef394f483ce12505ddd
Limited space for URLs on mobile browsers has given rise to a class of phishing attacks that rely on a carefully crafted URL with a long subdomain being cut off such as to give the impression of another, legitimate URL [1]. We've experimented in the past with avoiding this by showing only the base domain or the EV certificate owner, but had to revert to the old behaviour because of users complaining about not being able to see as much of the URL as formerly possible.
Making the displayed URL scrollable is therefore a nice solution: It allows us to choose the initial scroll position such as to put the focus on the base domain, while giving users the freedom to easily view all the rest of the URL without having to enter editing mode.
To make the URL scrollable, we wrap the TextView with a HorizontalScrollView. Alternatively, it would have been possible to use a ScrollingMovementMethod with the TextView, however that way
- flinging the text doesn't work out of the box
- dragging the text around is still detected as a normal long-press as well and triggers the context menu
[1]. E.g. https://manage-myaccount.paypal.com-webapps.verifcheck.com/signin/ (see https://twitter.com/ericlaw/status/900429796240277504 for an example screenshot).
MozReview-Commit-ID: LPEXQA2kBvD
--HG--
extra : rebase_source : dc5a9428a64cb8961b5783505f67599fa1e22f34
Our previous iteration of a more efficient fadingEdge implementation in FadedMultiColorTextView works by blending the text with a chosen colour. By choosing the same colour as the parent view onto which the TextView is placed, it was thus possible to achieve the impression of fading.
With our new URL bar design this is no longer possible quite as easily, since the image used for a lightweight theme will now be displayed behind the URL itself as well. Since the implementation would have also needed more work to make it compatible with scrolling text or being placed in a ScrollView anyway, the fading effect is now achieved directly via the ScrollView instead.
Android's built-in fadingEdge implementation calls Canvas.saveLayer (with CLIP_TO_LAYER_SAVE_FLAG omitted!) during a View's onDraw in order to fade out the contents of its children while preserving the background provided by its parents. This saveLayer call is rather expensive and is quite noticeable on a GPU profile even today.
Therefore, we implement a more efficient variety of fadingEdges that paints over its children's content in onDrawForeground. To avoid any background content from being faded out, the whole view then has to be placed on a separate layer, however this is still much more efficient than calling Canvas.saveLayer and doesn't show up noticeably in a GPU profile.
Prior to Marshmallow, onDrawForeground is not available, so we have to override draw instead in order to be able to paint over the content drawn by the ScrollView's descendants. This means that e.g. scrollbars would be faded out as well, but as we don't intend on showing a scrollbar within the context of this bug, it is an acceptable compromise.
MozReview-Commit-ID: DCDPt6ogs0h
--HG--
extra : rebase_source : eae7088d00918d0b6e7a8088fc414ac5adfdff9d
Our new animated progress bar follows the logic to hide itself:
1. When its progress value reaches 100, it disappears gracefully(with animation), otherwise,
2. It just disappears directly.
To make sure the progress bar always looked like fully loaded, we have to set its progress value to 100 before hiding it.
MozReview-Commit-ID: JSYEPYEhG4A
--HG--
extra : rebase_source : 6a432f093abb188f43da8ee3980c7681577c4f2c
Gregory Szorc
Jim Chen
Michael Comella
Nathan Froyd
Botond Ballo
Christoph Kerschbaumer
Axel Hecht
Jing-wei Wu
Sebastian Hengst
Phil Ringnalda
Chenxia Liu
Ryan VanderMeulen
Dylan Roeh
Andrew Swan
Ethan
Grigory Kruglov
Julian_Chu
Nevin Chen
friedger
Nick Alexander
James Willcox
Erica Wright
Sebastian Kaspari
Wes Kocher
Eugen Sawin
Jan Henning
suneet
sajattack
Francois Marier
Dustin J. Mitchell
Makoto Kato
Edouard Oger
Mehdi Soleimannejad
Richard Newman