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
Unlike the previous changeset, we don't strip common subdomains because
"m.youtube.com" and "www.mozilla.org" can be informative and don't look bad
when you have a tld.
MozReview-Commit-ID: BOPH73pzAfh
--HG--
extra : rebase_source : 1c5f7dc4aec2b91a2929d24d5cdaf587a3715623
We strip common subdomains from subdomain.domain because things like
"m.youtube" and "www.mozilla" look really bad.
MozReview-Commit-ID: wmWdcL8p8C
--HG--
extra : rebase_source : 165b72395a28f745c9a4e4b82d72299e648615ed
I haven't tested this because it's very time-consuming for such a simple
change.
MozReview-Commit-ID: 7f4LLlBbrLw
--HG--
extra : rebase_source : ce8fbbbf2a745395f0986fd76442f72743dc68ca
Exception handling upstream is already in place, and will ensure that we degrade gracefully.
Push won't work, but we won't crash either.
MozReview-Commit-ID: EfDNoJu46zg
--HG--
extra : rebase_source : fab5546108b8da29b3b2e3c8ee02e6459e6fc6dc
We're using Touch- and HoverDelegates to increase the effective clickable area, so there's no need to actually pad the button itself, which disturbs the layout and eats into the space available for displaying the tab's title.
MozReview-Commit-ID: CKS2OIoS1xr
--HG--
extra : rebase_source : 1e67c7a4c9014156d4e21424cae805dc30d35608
When the device is rotated between portrait and landscape mode (or vice versa), the View's final size is not yet available during the first OnPreDrawListener call for some of the TabsLayoutItemViews. It would be possible to skip the listener removal, so this is no longer used as a one-shot listener, however onPreDraw is frequently called even when the View's dimensions haven't changed.
Therefore, we switch this to an OnLayoutChangeListener, which is more appropriate for what we need.
MozReview-Commit-ID: 6JAzXdEBxbL
--HG--
extra : rebase_source : dc5d5bb94c783cb4eb5045335b4da192a68fe512
This is more or less a straight copy of our TouchDelegateWithReset class adapted to using HoverEvents instead of TouchEvents.
MozReview-Commit-ID: KtQvf1is5xK
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/widget/TouchDelegateWithReset.java => mobile/android/base/java/org/mozilla/gecko/widget/HoverDelegateWithReset.java
extra : rebase_source : 80a45db00554ea6271f258c0d6ebf75b05f90032
We found sometimes Robocop operates wrong UI components when it deals with a complex layout.
Since default panel shows Activity Stream which contains complex UI components, we configure
bookmarks panel as default panel to keep the layout as simple as possible.
MozReview-Commit-ID: 12xhVOdlIRK
--HG--
extra : rebase_source : fcb1a42e8e0ccdb06fd17bcb14880ed4a650efc7
Free dirty pages appear as "page-cache" in about:memory reports, but
when minimizing memory, and more generally, on memory pressure, they're
currently not force-free()ed on desktop, while they are on mobile.
There doesn't seem to be much reason not to do it on desktop as well,
and it should help reduce the noise in "explicit" allocations measurements
on CI, too.
--HG--
extra : rebase_source : e477532dda5e72eb8797b5bcdc9060ca46106275
I don't want to call BitmapUtils.getBitmapFromDrawable() here for AdaptiveIconDrawable cause there might be performance impact if I create bitmap in main thread.
I'll use bug 1397174 to follow up this issue.
MozReview-Commit-ID: 64FE2MOk5g0
--HG--
extra : rebase_source : 041e0a5f9d7b4245650f5a229603818b11631b4e
These `bgcolor`s are the background colors of the new icons added in bug
1388379. I was originally intending to remove the bgcolor attribute in this
bug, which is why I didn't change the colors in the previous bug.
I decided not to remove the bgcolor attribute to avoid churn: we'd have to
maintain multiple permitted schemas for the region.properties (one where
bgcolor is required and one where it is not), update the documentation to
clarify the changes before and after Firefox 57, communicate the new format to
several partners, etc. It seemed easier to continue to require bgcolor and, if
there is transparency in the icon, we use bgcolor, otherwise we don't. This is
already the way distributions work: some icons have transparency, some don't!
In practice, the updated bgcolors on the suggested sites doesn't make a
difference: there is no transparency in the new icons so these bgcolors are
never shown.
MozReview-Commit-ID: GovUjM7VKyG
--HG--
extra : rebase_source : 11b4a710c1d81e701568c7d83ab6155cf4bc1229
