onTabLoad() means we've potentially navigated to a new page, in which case any auxiliary tab data we keep around for the currently loaded page only (form input data, scroll position) would be invalidated and shouldn't be preserved.
Since onTabLoad() can however also be triggered if e.g. just the tab title changed (an additional DOMTitleChanged event), we shouldn't throw away the old data without replacing it with the current state, though. We already do this for the form input data - we need to do it for the scroll position as well.
MozReview-Commit-ID: HG7g6L7htDG
--HG--
extra : rebase_source : 1f7aab26002ee71237dd0a48b872298b39ca7f13
Launching a new activity within our app triggers both onActivityPause() (the current activity) and onActivityResume() (the new activity) in GeckoApplication. The most prominent example at the moment are probably our preferences - entering/exiting/navigating within them always triggers a pause/resume combo. This means that currently each time this happens, the network manager is stopped only to be immediately restarted.
To prevent this, we now stop the network manager only when Gecko is actually being paused. In order to avoid unmatched start/stop calls, we need to treat the calls to start() similarly and provide an additional code path for the initial call to start() immediately after startup.
Since the BatteryManager is only started and currently never stopped, we can use this for its startup, too, so as to avoid duplicated calls to its start() method.
MozReview-Commit-ID: 6NdScT5cLYL
--HG--
extra : rebase_source : 758a5948e0852bfa29c78d2d364cd5ac88e9103d
Currently, GeckoPreferences always returns "false" for isGeckoActivityOpened(), which means that when we're e.g. opening a new settings screen, GeckoApplication's onActivityPause() code assumes that Firefox is being backgrounded for real, calling GeckoThread.onPause(). This is then immediately followed by a call to onActivityResume() which unpauses Gecko again.
To avoid this, GeckoPreferences needs to properly implement support for GeckoActivityStatus and check the target of outgoing intents along the lines of the implementation in GeckoActivity.
Since checkIfGeckoActivity() is now used outside GeckoActivity as well, we refactor it into our IntentUtils.
MozReview-Commit-ID: UfPNAic5os
--HG--
extra : rebase_source : d8e900140f55f9a363b86064eb1ad8f8ee4c5c48
Launching a new activity within our app triggers both onActivityPause() (the current activity) and onActivityResume() (the new activity) in GeckoApplication. The most prominent example at the moment are probably our preferences - entering/exiting/navigating within them always triggers a pause/resume combo. This means that currently each time this happens, the network manager is stopped only to be immediately restarted.
To prevent this, we now stop the network manager only when Gecko is actually being paused. In order to avoid unmatched start/stop calls, we need to treat the calls to start() similarly and provide an additional code path for the initial call to start() immediately after startup.
Since the BatteryManager is only started and currently never stopped, we can use this for its startup, too, so as to avoid duplicated calls to its start() method.
MozReview-Commit-ID: 6NdScT5cLYL
--HG--
extra : rebase_source : 629d9a252125cfe4db1c30d6fcbe6607ac81ab33
Since we're no longer pausing Gecko when entering this activity, it must implement this interface so we can still properly pause Gecko if we get backgrounded while on the Sync preferences screen.
Most actions here are actually done via the application context (i.e. GeckoApplication), so overriding startActivity et al. and using mGeckoActivityOpened doesn't achieve all that much for most cases, but since we currently at most exit the screen (activity is finishing, so won't trigger a GeckoThread.onPause() call) and stay within our application (open a new tab in Firefox), we're still fine for now.
MozReview-Commit-ID: 3760hXMjckX
--HG--
extra : rebase_source : 026654ca101082140f9fbbc922562f9890daab50
Currently, GeckoPreferences always returns "false" for isGeckoActivityOpened(), which means that when we're e.g. opening a new settings screen, GeckoApplication's onActivityPause() code assumes that Firefox is being backgrounded for real, calling GeckoThread.onPause(). This is then immediately followed by a call to onActivityResume() which unpauses Gecko again.
To avoid this, GeckoPreferences needs to properly implement support for GeckoActivityStatus and check the target of outgoing intents along the lines of the implementation in GeckoActivity.
Since checkIfGeckoActivity() is now used outside GeckoActivity as well, we refactor it into our IntentUtils.
MozReview-Commit-ID: UfPNAic5os
--HG--
extra : rebase_source : 6167836e9a20763724c62aade1d2f0a5e976a890
Update to the point release. These are repacks of the
upstream builds for 1.15.1 stable with appropriate
libstd builds for each target.
This incorporates the -fPIC fix for linux32 so we can
use upstream builds instead of our patched toolchain.
It also corrects the signature of vec::IntoIter::as_mut_slice
which was incorrect in 1.15.0.
MozReview-Commit-ID: JvEdGPwgS03
--HG--
extra : rebase_source : 9edd9970d8328274311493c2c3c4fffa97b258a9
There's apparently a bug which causes *both* paddingRight and paddingEnd to be
applied (in my case on an API 23 emulator); the workaround, in this case, is to
also specify paddingLeft and paddingStart (with values "0dp").
MozReview-Commit-ID: 98hm1GcSPxi
--HG--
extra : rebase_source : 90b63521b410836615134eb7310ac0c2fb15081b
If the intent from 3rd-party app doesn't have data url, directly call
PendingIntent.send() will perform nothing. To use current url as
polyfill to fix it.
MozReview-Commit-ID: IIP7hGd1cBH
--HG--
extra : rebase_source : 14010c9f0b566e1320598a2edc0a6538d9c6150e
Suggested sites don't have a bookmark ID, there's little value in setting one here since
that's confusing for anyone handling the cursor. (This is probably an oversight from
when the single-cursor topsites query was first implemented.)
MozReview-Commit-ID: 77Cw37za6cD
--HG--
extra : rebase_source : 4e654b64d76423133bcfe4c90dab13891dcc4f09
Suggested sites aren't joined against the bookmarks table before returning
them as part of getTopSites(), so their bookmark state is unknown.
MozReview-Commit-ID: C5BhUcoSsll
--HG--
extra : rebase_source : 4509eb9980970de703e7f32ca371c76ec78b2673
The refactor patch removed a try/catch block that would have caught this
error before. Instead of using try/catch, this patch checks for the
affected items and send an error when the items are missing.
JSONObject.optString defaults to empty string ("") if the key doesn't
exist, whereas GeckoBundle.getString defaults to null if the key doesn't
exist. So the correct conversion for `json.optString("foo")` should be
`bundle.getString("foo", "")`. This patch fixes the wrong conversions
from before. In case we did default to null, this patch gets rid of the
redundant null second argument to GeckoBundle.getString.
Follow-up to fix breakage in accessibility caused by the bundle
conversion. In particular, optString(foo) should have been converted to
getString(foo, "") because optString returns "" by default.
Also fix a small bug in Presentation.jsm where an array or null should
be used instead of a string.
Repack of the upstream builds of the rust 1.15.0 stable release.
MozReview-Commit-ID: KDjkSQSFrFA
--HG--
extra : rebase_source : 7ca562b3d1cc4d051d9cfc25ef14fbbe2dbd77bb
They use an older version of Sencha Touch (v2.1.0) which is known
to not be compatibile with Firefox. However, pretending to be Chrome
fixes the issue of not being able to scroll and various paint bugs.
MozReview-Commit-ID: K35ll42Xxlt
--HG--
extra : rebase_source : 26f2e68ff2bc6be7d00a3eba1bedd56a9a7d62be
It seems that there is a wide variety of affected devices, so we should just play it safe
and run the workaround on any device that might be affected. (We already run this code
for _all_ devices for the main app menu, so it doesn't have any adverse affects. On the other
hand it would be nice to remove it eventually, i.e. once we no longer support Android 4 or 5 -
although that's still a long way away.))
MozReview-Commit-ID: 2nOYScRXQLd
--HG--
extra : rebase_source : 4e157683ac0de78f2ffb7336a7d0a0c7b483c502
For homepanels we usually send a long ID string (see the list in HomeConfig). We
reuse the topsites panel to render ActivityStream, so topsites and AS have the
same panel ID. It seems simplest to just override the session name when showing
AS.
MozReview-Commit-ID: JqyyqY77Eo3
--HG--
extra : rebase_source : cd372a4de91c550f30754d40f80ef8c86f6eb1c8
We currently only start a session when swiping between homepanels. We should also send
it when showing the homepanel normally.
MozReview-Commit-ID: 8Kk2RDCbDDc
--HG--
extra : rebase_source : 113474aa6efe5a7e25a2b96a6db5bc049a12d7cf
The Samsung Internet content provider provides both bookmarks and folders,
distinguished by "bookmark_type" (equals 0 for folder, 1 for bookmark). We're
currently importing both types, with folders getting inserted into our db with a
url of null. Such "bookmarks" never seem to surface in UI, and sync ignores
them, but let's stop importing them anyway.
MozReview-Commit-ID: 7G3QuEYBgRb
--HG--
extra : rebase_source : 965e704c5b4d470f90c1e89a69e64d4203374a27
3rd-party-app could launch CustomTabsActivity, and could also configure
a custom action button. Now let CustomTabsActivity supports it by
creating a MenuItem.
MozReview-Commit-ID: 2KuMgBJy2gz
--HG--
extra : rebase_source : 93bcfb33001005d307dba68f898375ab7d86adb2
To support ActionButton in CustomTabsActivity, information should be
extract from intent.
MozReview-Commit-ID: 3C19U0EQfV6
--HG--
extra : rebase_source : a8d941a3fd740d5d8863e748b20de790b8bf589c
This variable is useless. So far we reference to a toolbar instance by
local variable. Removing it makes less ambiguous.
MozReview-Commit-ID: 8zrEKaB2H48
--HG--
extra : rebase_source : e35e3f87876ca497745585134018cff41536b9b0
