Use the GeckoService load-libs action to load and extract new libraries
when we receive the update broadcast. This makes us not block the UI
thread to extract libs, and lets Fennec run normally if the user
launches Fennec right after updating.
When GeckoThread is launched without being initialized, it will load all
Gecko libs and then wait until it is initialized, before calling the
Gecko entry point. This allows us to preload Gecko libs without actually
running Gecko.
Some x86 devices set the CPU ABI to ARM (and even change /proc/cpuinfo)
as part of emulating ARM. In that case, we check the kernel release
string find out whether it's really x86 or not.
Compound drawables shift the point where text is "centered". This hack dynamically adds
equivalent padding on the opposite side from a compound drawable, to force the text
to be centered again. (We can't set this padding under all circumstances, it's unneeded
when the text is longer than the available space, i.e. when we wrap text we might
as well use the full width without fake padding.)
MozReview-Commit-ID: 8WDXCNOs2DX
--HG--
extra : rebase_source : d844e71587a7bd78233d88ea209b157a43004e09
Text is currently pushed directly against the pin in those cases
where the entire width is filled with text - this spacing
is needed to separate the pin, and text.
MozReview-Commit-ID: HOVH1SgcrLY
--HG--
extra : rebase_source : cfa33274601c419a39622c081c3e19298d5ff44f
Even if we do the rest of our location change processing only for top level location changes, we still need to update the state of the back and forward buttons even on subframe navigation, so they can become enabled/disabled as necessary.
MozReview-Commit-ID: 2wuFZMKtTfj
--HG--
extra : rebase_source : 6085fee3818b0ce610f2ddca3f8be0657f355916
We used to need these for the back button long press history menu, but now we no longer do.
MozReview-Commit-ID: LAZYffLODN3
--HG--
extra : rebase_source : b6c10e3dc785230d247587b1a34c3b819424db9c
This should be more foolproof than having to remember to use the dedicated setParentId() function when writing to that variable from outside of the tab constructor.
MozReview-Commit-ID: 1KlXf60VsoF
--HG--
extra : rebase_source : 3ae5234a0113b6077a91e873c7a5e5919b162af3
Fix copy & paste error made when creating the new test file.
MozReview-Commit-ID: F0NbwipkX9P
--HG--
extra : rebase_source : 877c2c867235750972ee7865d52376636b0448f6
During a cold startup, depending how this exactly plays out we might receive an application-foreground notification before the browser window is ready. Since the code to restore the selected tab if it has been left zombified while in background is only relevant if Gecko was already running and backgrounded, we can simply add a null check for the window before accessing it.
MozReview-Commit-ID: Ahp5NAODKRF
--HG--
extra : rebase_source : bede266e13f48fbc2f7efd40bb9277be6d2bd3bf
We've been displaying the URL in place of the page title in the toolbar for quite some time now, but still had the old logic in place whereby only title changes would trigger an update of the displayed text. Most of the time this works fine, because
- page navigation usually goes hand in hand with a DOMTitleChanged event, and
- when our loading progress bar stops, we update the displayed text anyway
however a page doing its navigation in-place using some fancy JS logic and the corresponding history APIs etc. can bypass both of these provisions, since it might trigger neither a title change nor a full browser-side page load.
MozReview-Commit-ID: KRrTSmz1xxi
--HG--
extra : rebase_source : ef3c96334ebb44320ffc7f77db0754f78ce0625a
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.
Jim Chen
Andrzej Hunt
Sebastian Hengst
Jean-Yves Avenard
Aki Sasaki
Jan Henning
Phil Ringnalda
Christoph Kerschbaumer
Kris Maglione
Wes Kocher
Ralph Giles
Tom Klein
Julian_Chu
Nevin Chen
Carsten "Tomcat" Book
Aman Dwivedi
Grigory Kruglov