We don't update ToolbarDisplayLayout when it's not ready (i.e. when it's
not attached to a window yet), but when it does become ready, we should
update it to the selected tab, if any.
Changes in the BrowserDB, e.g. because of sync or when opening a link (in a new tab) will trigger the BookmarksLoader's onContentChanged() method, which will trigger a new load reusing the current loader. This means that currently, the code for setting the scroll position in onLoadFinished() gets to run again in that case.
We only want to set the scroll position when the user has navigated to a different folder. Folder navigation will always create a fresh loader, therefore we now keep track whether we've already seen a particular loader in onLoadFinished() and only set the scroll position if we're encountering this particular BookmarksLoader instance for the first time.
MozReview-Commit-ID: Ln8yeUEoEfr
--HG--
extra : rebase_source : a32c33080f56071059898127c19c75e3d32b3a3b
More JPZ leftovers, I presume. In any case what's left doesn't do anything really useful and a DXR search didn't reveal any remaining users, so this can be thrown out.
MozReview-Commit-ID: 9dN6Jifpbvw
--HG--
extra : rebase_source : 04614d729a55e00c5331ecc321ca2ef5b5e73747
Collecting data for history changes causes an additional session store data update for that tab when navigating back, which needs to be accounted for in this test. Therefore we now also wait for DOMTitleChanged before assuming that the tab has navigated to its intended location.
MozReview-Commit-ID: FDNQednXPWh
--HG--
extra : rebase_source : c38b4085eac914bb9a3aa4f0e2b1e04eb3cf1ce3
So far we've simply used DOMTitleChanged as a proxy for navigation, since it's the earliest opportunity at which we have all necessary data for a new history entry (session history itself as well as tab URL and *title*) available.
However it turns out that this is not 100 % reliable, since some pages might e.g. implement their navigation in JS using the history API, which won't necessarily trigger any DOMTitleChanged events. In those case we'd fail to update the tab's session history in the session store unless the user eventually navigated to someplace else that actually triggers a title change event again - if the browser was closed before that, we'd fail to properly restore the user's state.
To fix this, we take a similar approach as the desktop session store and collect a tab's history data again when receiving any history change notification for that tab.
Because the OnHistory... notifications are mostly cancellable, the session history hasn't been actually updated yet at the point the history listener is being called. We therefore can't synchronously call onTabLoad() from within our history change notification handler and have to schedule an async timeout instead so as to give the session history a chance to complete updating its state.
MozReview-Commit-ID: LgHer940QwT
--HG--
extra : rebase_source : a9634be57f3f43e30f42431e8a28846d958534ee
Since we don't want to show the media control for the short sound, so we added the duration checking.
And this checking only needs to be run when the media is active, we don't need to check the inactive media.
MozReview-Commit-ID: AaVGi77nXJ1
--HG--
extra : rebase_source : c565fe64ec4030f0519eb0a8cfe493e95bae4fe4
Since BBC website puts their audio in another iframe, we can't get the media
element to check its duration, so we always return false.
The ideal way to fix it is to get every iframe and check its element, but I think
it's not very easy to do considering the flexibility of using iframe and the cost time.
First, if we want to get the information inside iframe, we need to listen the
onload event, but it's async operation. If there are lots iframe, we need to spend
lots time to wait every iframe. The worst situation is we got the nested iframe,
it would need lots time and effect to wait every iframe loaded and get the element we want.
Therefore, I would prefer the workaround which is to reverse the checking condition,
that is we only check duration for the main window.
MozReview-Commit-ID: F93BjbzRMXO
--HG--
extra : rebase_source : 9409649db241b466967ab1e7f467e177c06c728f
Currently, Recently Closed is displaying the last available history entry for each closed tab instead of the history entry that was actually being shown at the time the tab was closed.
The Java session parser that is responsible for displaying the last session's tabs when not automatically restoring is already doing the correct thing and therefore doesn't need changing.
MozReview-Commit-ID: DGaD52SzdpP
--HG--
extra : rebase_source : 0f11b32d3d8f1061681706272b62dfb090e8e598
Previous state:
- Two threads were racing to get to batchMeta - one to reset its state, and the other to
read its internal state to construct a network request, and then to update its internal state.
- This resulted in data corruption when payloads had to be split into multiple batches.
A core problem was that there is a lot of state shared across thread boundaries. Specifically,
BatchMeta is being written and read both by record consumer threads running off of a thread pool,
and by the network worker thread(s).
This patch refactors BatchMeta and scheduling of network runnables to ensure that cross-thread access
is minimized, and "who owns/accesses what" is explicit.
- PayloadDispatcher owns scheduling payload runnables and any data they need to share between each other.
- UploaderMeta owns information that's necessary to process incoming records.
MozReview-Commit-ID: 9hFs3fXGaGM
--HG--
rename : mobile/android/services/src/main/java/org/mozilla/gecko/sync/repositories/uploaders/BatchMeta.java => mobile/android/services/src/main/java/org/mozilla/gecko/sync/repositories/uploaders/UploaderMeta.java
rename : mobile/android/tests/background/junit4/src/org/mozilla/gecko/sync/repositories/uploaders/BatchMetaTest.java => mobile/android/tests/background/junit4/src/org/mozilla/gecko/sync/repositories/uploaders/UploaderMetaTest.java
extra : rebase_source : f0f1a05f19f40a6514d4f0dac9d531b086c3f3ed
In phoneRegex, replace '\\s ' (matching a whitespace character) with ' '
since phone number won't contain something like new line or tab.
Also, consider it done if selected text is not changed after calling
Modify().
MozReview-Commit-ID: 2lB9w2gYCOD
--HG--
extra : rebase_source : f2ea498bbd17c1876a9b7f769cbe93cef84520bb
I don't think we ever check this attribute in our code and rely on the presence of "__SS_restore" instead, but we should fix this for consistency and any add-ons or future code that might depend on this.
MozReview-Commit-ID: JwB6kpiKsaR
--HG--
extra : rebase_source : a3c98f4c76a67a8c1a42e1740cf09ab121f8f5b5
By default RecyclerView assumes any item change *might* need animation. It then
creates a new copy of the item that has changed, and interpolates between the two
to "animate" the change. We don't need that for topsites (the RecyclerView's we use
inside each TopSitePanel already animate changes, the overall size doesn't change -
moreover ViewPager state gets lost if you create a new panel), so we override
this behaviour to retain the existing panel. This stops the previously visible
horrible flickering.
(Every time history changes, which can happen if sync is working, or even if a page
finishes loading in the background, the DB is changed, and a reload is triggered.
Prior to this commit, topsites would flicker horribly, and would reset back to the first
topsites page. After this commit the page is retained, and the visible topsites
are rearranged by the inner RecyclerView's animations. You can test this by pinning a
site on the first page, the pinned site will shift to the front, the other sites smoothly
move to the right.)
MozReview-Commit-ID: CnocNfdQ2FS
--HG--
extra : rebase_source : 3a4e1d86c786126aee1e08ab020b855056e4f921
If we clear and recreate pages every time the cursor changes, we'll (A) lose
the current page position and (B) create a new RecyclerView per page, resulting
in flickering. We also need to make sure positioning is correctly handled (i.e. pages
never move, they only get added or removed).
We also switch to an ArrayList: the number of pages will be fixed for most users,
and searching an ArrayList could potentially be slightly faster than with the LinkedList.
There's little advantage to a LinkedList here.
MozReview-Commit-ID: 6NIfc2otQMV
--HG--
extra : rebase_source : 86b51be92c18e791f8049b5c90441370c6bace9a
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
Added support for changing default browser by opening settings screen in API Levels >=24.
MozReview-Commit-ID: 5rxJm6hQQ4A
--HG--
extra : rebase_source : e8fc23bc658e216c04c27e10067c16abf2b0cd5c
There are a number of ways in which we could supply favicons for the default suggested
sites. Reusing the touch tiles has the advantage that it works for both our own suggested
sites, and also distribution-supplied suggested sites. If we were to add yet another
icon source, distribution supplied sites would end up having no nice icon in AS topsites.
The priority ordering of the SuggestedSitePreparer means icons will be overriden as soon
as a site-supplied favicon is available - these icons will only be used up until the point
where a site has been visited.
MozReview-Commit-ID: CHsinHHpfnw
--HG--
extra : rebase_source : a162f5b15e968f382b43505290b0633cbe6e2c7a
In order to allow for a background which merges into a favicon, we
need to allow for solid (non faded) colours. It is simplest to do this
by letting the colour generator (i.e. either the colour extractor,
or the favicon generator) fade the dominant colour as it wishes.
That also means the colour generator can in future choose to
not fade the colour if appropriate.
MozReview-Commit-ID: LsI8PlZsaGn
--HG--
extra : rebase_source : 757f10613a201475edb81afc094f32d5a714ade2
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
