The shared preferences keys used for storing/retrieving the activity list data are constants, so it is a bit disconcerting to see them named like normal member variables.
MozReview-Commit-ID: GivVloU0pFv
--HG--
extra : rebase_source : e26bcabd1cdf549e8a0ee54f0e6333c76484ca24
We need to access sessionToken in the Engaged state in order to perform device
registration. We expose getSessionToken() on the base State class, to allow
customers to get the sessionToken easily instead of having to downcast the
TokensAndKeysState/Engaged states.
MozReview-Commit-ID: 8s2C350noUG
--HG--
extra : rebase_source : e0bc8bf7ebfdcb7a31bb4a6ddb5b928acf7baba9
If user long click text area of ActionBar(URL or Title), then copy
current URL to clipboard.
MozReview-Commit-ID: EdVoMiX0Gt3
--HG--
extra : rebase_source : eecd78325162bb5c0a41436b90d0e10f5669030c
This assumes that the observed test failure was caused by the async file delete triggered by the history sanitisation in test_sessionStoreClearTabHistory being somehow delayed long enough to only take place after we had already started test_sessionStoreClearFiles.
MozReview-Commit-ID: FenpPyb4sGZ
--HG--
extra : rebase_source : 3f14e1053b043a03aac1680ee56483243b5a4045
CLOSED TREE
Backed out changeset 4ac559eea9ec (bug 1348803)
Backed out changeset 2ab6e0b8aec6 (bug 1348803)
Backed out changeset f966aef934b1 (bug 1348803)
Other events in browser.js are all lower case letter, also change these two to make them consistent.
MozReview-Commit-ID: LkzYUo6OrEA
--HG--
extra : rebase_source : 8b134332e32cae29a1f963e604f2507433c694b8
We could register media control related event after the tab has active media.
But we still need to register "audioFocusChange" in the beginning, because it
affect every tab even the tab has no active media.
MozReview-Commit-ID: 4pBKIR8F5tV
--HG--
extra : rebase_source : fc26c98ed7b33552b4eba5b20168394b1b1a4390
__Device_Configuration__|__o_Applied_Style_______________
ldrtl-v17 v17 v15 |
o o o | UrlBar.Entry
\ | | |
-----o | | UrlBar.V17.Entry(start/end)
\ | |
\ o | UrlBar.V15.Entry(left/right)
\ | |
--o | UrlBar.Base.Entry(original style)
Though Android support RTL since API level 17(JB_MR1), it's really buggy at that moment.
This patch fix a severe UI layout attribute bug, which only happen on android 4.2 in RTL language context:
If view attributes "start/end" and "left/right" are both written in a view layout xml, they will both be applied and cause UI abnormal. In API 18 and above, "left" will be ignored if "start" also exist.
For example, as below show, alignLeft and alignStart are both exist in ImageView. On android 4.2 with RTL context, it's width will both align Left and Start(Right), cause the symptom that ImageView have the same width and cover on the view "back."
```
<ImageView android:id="@+id/url_bar_entry"
android:layout_alignLeft="@+id/back"
android:layout_alignStart="@+id/back"
```
MozReview-Commit-ID: JptLuWX2w15
--HG--
extra : rebase_source : ef89a31f77f56f6f4e936e20644c243abfa7239f
Change filter_py to only report on toolkit files referenced in
mobile/locales/jar.mn.
We ignore netwerk, security/manager, devtools/shared, services/sync
on the module level.
MozReview-Commit-ID: 4YRwZHUD1gE
--HG--
extra : rebase_source : 2613456c9c3442ba2d27468fdc106c1778273f6f
This commit adds a check for not prompting the user in case
the permissions have already been granted for accessing
file:// uris
MozReview-Commit-ID: A62AUqqTJSb
--HG--
extra : rebase_source : c5109c2fede109e1942cce240e26b12a220e8574
Generate a separate omni.ja for GeckoView during the packaging step,
under dist/geckoview. Define a MOZ_GECKOVIEW_JAR flag to optionally
include/exclude files in the package manifest.
Expand the existing test by navigating to a different page and then going back after the tab has been restored again.
Proper restoration of the zoom level for anything other than the current history entry depends on resolution of bug 1312605.
MozReview-Commit-ID: Aspg2RRcY53
--HG--
extra : rebase_source : 4c70ebc82c682878506005007798db4fda0a613e
Just as the comparable test on desktop we should use a really big document with enough space for scrolling in both Y *and* X directions. We should also randomise the scroll positions used for testing instead of hardcoding them.
MozReview-Commit-ID: 9FvaOnaKJ6
--HG--
extra : rebase_source : af57219a92a7ad84a58c186fde9bd4c60ef16a76
We are going to need this in the future and starting collection even before releasing
Activity Stream will create a better experience once we turn it on.
And this flag is hard to miss. So let's just get rid of it.
MozReview-Commit-ID: 5oDzXhpQdSA
--HG--
extra : rebase_source : c96800257070af9287d5236625150dbb62985c4b
This is a bit complicated. But most of that code should go away again as soon as
we can stop shipping the opt-out preference.
With this patch we have three flags that can be controlled via Switchboard:
* activity-stream: This is our global kill switch and allows us to pull the feature
if needed. A user has to be in this experiment to ever see activity stream. The
goal is to enable this experiment for 100% of the Nightly audience.
* activity-stream-opt-out: This is experiment will enable the Activity Stream by
default. The goal is to enable this experiment for 50% of the Nightly audience.
* activity-stream-settings: This experiment controls the visibility of a setting
to enable/disable activity stream (settings -> advanced -> experimental features).
This allows us to control whether users can opt-in or opt-out of the activity
experiment. The goal is to enable this for 100% of the Nightly audience.
MozReview-Commit-ID: BwEoTK6QMQx
--HG--
extra : rebase_source : dbe9815127c1aa620bbc2f1623aa4726438d3285
It's not used anywhere in gecko or addons. Remove it will make
removing PScreenManager easier.
MozReview-Commit-ID: K3BHnktO7wU
--HG--
extra : rebase_source : 6f481759d1fb82d222ea6a92ebfd50dbb6cb63d5
Media control would also be displayed for non-audible media, we shouldn't
arbitrary request audio focus . Only request audio focus from gecko which know
whether the media is audible.
MozReview-Commit-ID: Ke9DCYd0Qh2
--HG--
extra : rebase_source : 6ca2f83de877495f7249ee5e7f5cf2165f6f7f6b
This means scaling the the size of the images used for buttons and making sure that at large magnifications, the toolbar's text input properly moves into its own line instead of simply overlapping the preference immediately below. We also want to make sure that the text on any buttons remains vertically centred.
MozReview-Commit-ID: 7rUf1tucAzL
--HG--
extra : rebase_source : d227729955d15bc74d7502e116d0e71b97d76828
A basic check that the listener is indeed operational.
MozReview-Commit-ID: 6KijcsRaScI
--HG--
extra : rebase_source : c999d7bd78101f16efffedbfddbce89c83b39f9c
We can use this function for our upcoming test as well, so we should move it into the common header.
MozReview-Commit-ID: H5ANDAlnpmm
--HG--
extra : rebase_source : 9d873d45ec7f701bc993e3b5f676c0638d58656d
The state of the switch added in Part 4 is stored in our Android-side shared preferences. For this to have any actual effect on rendering, we now add a class that is initialised when Gecko starts up and listens to changes of that particular pref.
When it is turned on, we enable font inflation and add another listener for the system font scale, which then forwards the current font scale as well as any changes to Gecko, so mobile mode pages can be scaled correspondingly as well.
When the setting is turned back off again, the system font scale listener is stopped again and the Gecko font size settings reverted back to their default values.
MozReview-Commit-ID: GyffpZTQQX8
--HG--
extra : rebase_source : 23fcadbf04505f78ff1531c5d3c212d4f98eab9e
After landing bug 1300884 and B2G is dead, Web Alarm API is removed. So we should remove Android backend for Alarm API. This implementation was for B2GDroid.
MozReview-Commit-ID: ItmjOQrVSgs
--HG--
extra : rebase_source : 1844b81c515c043245c9bed034698a1904f03286
Merge "DOMServiceWorkerFocusClient" & "DOMWebNotificationClicked"
to "DOMWindowFocus" event. Utilize the event to switch tab when
loading links to an existing target tab.
MozReview-Commit-ID: Hd1NkVkrJA1
--HG--
extra : rebase_source : 745c0d66c3afd8e487c616891c0f10bd820da1fe
If 3-rd party app specify to use tint for Action Button, use primary
text color as the tint color for Action Button.
MozReview-Commit-ID: 3sX0MH8P0dM
--HG--
extra : rebase_source : a50256dd16675f2a329eb182c6aed9e564386315
This patch changes the crashreporter client code as well as the crash service
code to compute a SHA256 hash of a crash' minidump file and add it to the
crash ping. The crash service code computes the hash on the fly before handing
over the crash to the crash manager; the crash manager will then add it to the
crash ping. The crashreporter client on the other hand sends the hash via the
ping it generates but it also adds it to the event file so that the crash
manager can pick it up and send it along with its own crash ping. On Fennec
the crashreporter activity takes care of computing the hash.
SHA256 hash computation uses nsICryptoHash in the crash service, the
java.security.MessageDigest class in Fennec, the bundled NSS library in the
crashreporter when running on Windows and Mac and the system-provided NSS
library under Linux. The latter is required because the crashreporter client
uses the system curl library which is linked to NSS and which would thus clash
with the bundled one if used together.
This patch introduces two new methods for the nsICrashService interface:
|getMinidumpForID()| and |getExtraFileForID()|, these reliably retrieve the
.dmp and .extra files associated with a crash and ensure the files exist
before returning. These new methods are used in the CrashService for
processing and will become the only way to reliably retrieve those files
from a crash ID.
MozReview-Commit-ID: 8BKvqj6URcO
--HG--
extra : source : a4d8291c56fcde00238ab3166bbe6af6dd602340
To gauge the impact of bug 1343995 on perceived shutdown times, we want to measure how long sanitising actually takes in practice on Android.
MozReview-Commit-ID: 3gSfT8IoO70
--HG--
extra : rebase_source : 19ffdfbf1005ae4beebaa0c9d8befea31e1aa01f
This'll allow customising context menu/session store/... behaviour in Gecko depending on the tab type, since in the future we might not only have special behaviour for custom tabs, but for web app tabs etc. as well.
MozReview-Commit-ID: LS6oGfO4KpR
--HG--
extra : rebase_source : 677a013a05cc683cae82c84864509d8f4799b474
Custom tabs etc. shouldn't show up in the main browser activity.
MozReview-Commit-ID: 1yrLZP6HJ3e
--HG--
extra : rebase_source : 6f3a1b8149d4747ef665f1a90a589940d12526a9
We always want at least one browsing type tab open to match current behaviour and assumptions built into the app, but the same doesn't hold true for other tab types. A CustomTabActivity instance e.g. only holds a single tab, so the lifetime of the tab is tied to the lifetime of the CustomTabActivity. If we're exiting the activity, we just want to close the corresponding tab without opening a new replacement for it.
Since we have to select some other tab instead in that case (so the selected tab in the tab list and the selected tab in Gecko remain in sync and so we always have a selected tab), getNextTab() therefore has to fall back to browsing-type tabs as a default if no other tabs of the same type are available.
MozReview-Commit-ID: IpvINlu5Qq9
--HG--
extra : rebase_source : 6b934209c06dd8ed2b199f92a768a37c028bb689
As long as the tabs are opened in the same Gecko browser window, splitting the Java UI tabs list into multiple parts breaks too many assumptions, so the easier solution is to allow setting a type attribute on each tab object, which will allow filtering of them later on.
MozReview-Commit-ID: 1PbxMkWTK47
--HG--
extra : rebase_source : ea7b82271b681e04590046a1d5cf9c2230729781
To add a progressbar to CustomTabsActivity then user knows page loading
progress.
MozReview-Commit-ID: L1Qc7Oj81bZ
--HG--
extra : rebase_source : c55813f271d3bbdaacf485809290c935d2b6ef7b
No need to create id resources for common widgets in each activities, e.g.
toolbar. Reuse id resources to make less ambiguous when invoking `findViewById`
In BrowserApp and CustomTabsActivity, both of them have ActionBar and
Progress-Bar. Let them use the same id resource.
MozReview-Commit-ID: 2jq18dwlBlm
--HG--
extra : rebase_source : 7d8d2bcb3da6969b1471e267527f27ea1bbeaab7