Style varies across the tree, and this matters as we transition to
Python and moz.build. AppConstants.jsm already uses #ifdef, so this
is consistent with that.
MozReview-Commit-ID: Bal37lqlvjq
--HG--
extra : rebase_source : 8e4e459a9bdbc3a2cacde728f45e6edecc272e24
That pref isn't set by default, so trying to access it in that case throws a JS error.
MozReview-Commit-ID: 2KIUSztvoXS
--HG--
extra : rebase_source : b2769ba16247db9373c004f152c0e2233fb0652d
* nightly-aurora-id is a copy of nightly
* mobile/android/branding/aurora/ is a copy of nightly with the id and package name changed
MozReview-Commit-ID: 2VT0dHDXEMg
--HG--
extra : rebase_source : 7396a1a7eabb4037fb6936bfc1af10666a677e14
There is a control in menu for reloading or stop-page-loading. Its icon
should be updated per page loading progress.
MozReview-Commit-ID: BNanAQj3xS4
--HG--
extra : rebase_source : 9964c320f3e430583fcdd79034c834af0c115fbc
If change icon via resource id, we should create mIcon as well. And
method `getIcon` should return the drawable which be used currently, but
not generating a new drawable via resource id.
Without this patch, we cannot change icon of a GeckoMenuItem until we
set the icon back. ie.
Drawable icon = menuItem.getIcon();
icon.setLevel(42); // does not work, cause the icon is new instance.
MozReview-Commit-ID: KxW66OgI9po
--HG--
extra : rebase_source : 7b9c1dc13d9b3b214e5dcb3ee366dca7e60f3fe7
Android shows a dialog box when it detects app crashing. OOP decoder needs to hide that from user to resume playback gracefully.
MozReview-Commit-ID: 3cE3GiHAuQk
--HG--
extra : rebase_source : 67bec5dfda1e878fa7dea877ef58d485b4e17944
Add the necessary XPCOM components to handle prompts for GeckoView. The
JS code mostly package the prompts into GeckoView:Prompt events, and send
them to the Java side if in parent process, or to the parent process if
in child process.
Add an event listener for the GeckoView:Prompt event, which JS code will
use to sent over prompt requests and to receive prompt results. Both
global and per-GeckoView listeners are required because we may not know
the origin GeckoView for certain prompts, so some prompts will not have
an associated GeckoView. This is also the reason for having a static
default PromptDelegate in additional to an instance per-GeckoView
PromptDelegate. All prompts without associated GeckoViews are sent
directly to the default PromptDelegate.
Add a PromptDelegate interface that implements possible prompts shown by
a GeckoView application. All prompt methods include a callback parameter
for the implementation to call back to GeckoView with results from the
prompt.
CustomTabsActivity use standard ActionBar, so we can easily use action
mode for text-selection.
MozReview-Commit-ID: CSu0d24Z7dt
--HG--
extra : rebase_source : 9040e515a6208459aa5b0b7470e491c7474fe4ec
To create new interface ActionModePresenter, a presenter could to
operate action-mode.
For pre-marshmallow Android version, we use ActionBar to provide UI
action for text-selection. Therefore BrowserApp will implement this
presenter for text-selection.
MozReview-Commit-ID: GdLB3ke2pYe
--HG--
extra : rebase_source : 5467a7d514810fa846fefcf37e5eb2f55a643c3f
We want to reuse ActionBarTextSelection in more activities, so remove
custom classes from it, to make it easier to interactive with general
Andorid classes.
To achieve that
* Let ActionModeCompat to be a subclass of ActionMode
* Get rid of GeckoMenu
BrowserApp is the only one consumer for ActionModeCompat, and it do
understand the class type. We could move animateIn to it safely. After
doing this, TextSelectionActionModeCallback could become a general
ActionMode.Callback.
MozReview-Commit-ID: 7FTwDTe1JYG
--HG--
extra : rebase_source : cf7cbba40745bbfbd34099f238c904bb4d3c6438
This commit also cleans up extraneous stream closes: these streams
are closed in finally, so we don't need to also clean them up in
the main try block body.
MozReview-Commit-ID: EXxlmmtqvyq
--HG--
extra : amend_source : 72ad8cb816202e8e3f234157bae092cea004d34a
That helps usability in the following scenario:
1) Open more tabs than will fit on screen in the tabs tray (and fill the last
row with tabs if the tabs tray is in a grid mode);
2) Scroll to the bottom;
3) Open one of the last visible tabs, and from that open tab open a new
background tab (e.g. long click on a link in a page and choose "Open in new
tab");
4) Reopen the tabs tray.
With the fix, the new tab will be visible at the bottom of the list, whereas
previously in list mode it was not visible at all, and in grid modes only the
top of the title was visible.
(Bug 1299905 would make this sort of situation more widely applicable.)
This patch also has the side effect of scrolling the selected tab to the top of
the tabs tray on each rotation (previously it was just scrolled into view).
MozReview-Commit-ID: 4MKY7P1Mihk
--HG--
extra : rebase_source : a00776803b199a949ba598805e79a71fde82e2f3
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 : 6853dc40c68c0939d7e318b3a1e88c39495d0648
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: ErIBUobnxbg
--HG--
extra : rebase_source : bdc8070f2f2a81f847ebb8e0ec87f6efeb86eb80
Incoming records might be missing the dateAdded field, and so we perform some pre-processing:
- during reconciliation, dateAdded is set to the lowest of (remote lastModified, remote dateAdded, local dateAdded)
- during insertion, if dateAdded is missing it is set to lastModified
Whenever we modify dateAdded for a record during sync, we also bump its lastModified value. This will trigger an
upload of this record, and consequently a re-upload by clients which are able to provide an older dateAdded value.
It is possible that this might cause conflicts on other devices, but the expected likelyhood of that happening is low.
MozReview-Commit-ID: 3tDeXKSBgrO
--HG--
extra : rebase_source : 26cb13838df7a4adb6d4fe3c51f0ecf3fd2eda95
Add the aarch64-linux-android libstd to the android-cross
repackage of the upstream rust 1.16.0 stable builds.
MozReview-Commit-ID: gmZL7QCodQ
--HG--
extra : rebase_source : dc4072c3214188195aa6abda939d550df4e617d9
I'm taking another kick at this. Since glandium's negative review of
older patches a year ago, generate_build_config.py landed (with your
r+, gps). These patches extend that mechanism to generate
AndroidManifest.xml. This sets the stage for that.
This is all in service of Bug 1355625, which will need the
generate_build_config.py extension point to do things that the
preprocessor cannot handle: generating Java code, copying resource
files, and merging resource XML declarations.
MozReview-Commit-ID: AcyC3CBMQl1
--HG--
extra : rebase_source : c379b07de4b9f9b4bfe53e6a0adac13f08a71c73
This solves 2 issues:
- We keep a reference to Tracker (which is implemented by a Service) forever,
which is solved by keeping a WeakReference.
- We kept another reference to the Service by using it as a Context - we can
avoid that by using the ApplicationContext instead.
MozReview-Commit-ID: 6UNSkZx12an
--HG--
extra : rebase_source : bfb50d02246e4377ef23179747987bc82731fd54
The checked items are stored in a *sparse* Boolean array, which we want to transform into an array (list) of the checked indices for transmission to Gecko.
The current approach doesn't do this correctly, as it iterates over all (sparse and non-sparse) items, but uses SparseBooleanArray.size() (which only counts non-sparse items) as its iteration limit. This means that we only copy the checked state of the first n items, where n is the total count of checked items.
For correctly iterating over the array to retrieve all indices that are true, we'd either have to use the largest available key (if we'd want to iterate over everything, including the sparse indices), or else use the approach chosen in this patch, namely using valueAt/keyAt in order to iterate over the internal array that's storing the values for all non-sparse indices.
MozReview-Commit-ID: FRGI4Rr0uCb
--HG--
extra : rebase_source : d9bb3a08af3a7ee2e730beb4777df30d019c922c
I'm adding a helper function mozILocaleService::GetRequestedLocale to simplify
most of the callsites that are looking for the first of the requested locales.
In most cases, I'm just matching the behavior of the code with reusing
LocaleService API instead of direct manipulation on the prefs.
That includes how I handle error case scenarios.
In case of sdk/l10n/locale.js I am reusing LocaleService heuristics over
the custom one from the file since the ones in LocaleService are just
more correct and unified accross the whole platform.
In case of FallbackEncoding I have to turn it into a nsIObserver to listen
to intl:requested-locales-changed.
MozReview-Commit-ID: 7rOr2CovLK
--HG--
extra : rebase_source : 883a91b249b6953b7872bfb9a8851e8be7257c7b
I'm adding a helper function mozILocaleService::GetRequestedLocale to simplify
most of the callsites that are looking for the first of the requested locales.
In most cases, I'm just matching the behavior of the code with reusing
LocaleService API instead of direct manipulation on the prefs.
That includes how I handle error case scenarios.
In case of sdk/l10n/locale.js I am reusing LocaleService heuristics over
the custom one from the file since the ones in LocaleService are just
more correct and unified accross the whole platform.
In case of FallbackEncoding I have to turn it into a nsIObserver to listen
to intl:requested-locales-changed.
MozReview-Commit-ID: 7rOr2CovLK
--HG--
extra : rebase_source : 2f166cf1746f389a035f7cf557edcadeacb10fa0
This version of the Dynamic Toolbar moves the animation of the toolbar
from the Android UI thread to the compositor thread. All animation for
showing and hiding the toolbar are done with the compositor and a static
snapshot of the real toolbar.
MozReview-Commit-ID: BCe8zpbkWQt
Layer on the hacks! This:
1) Reinstates the <activity-alias android:name=".App"> that we have in
the moz.build produced Android manifest. I found no way to do this
using placeholders or the manifest merger.
2) Culls manifest entries provided by
com.google.android.gms.measurement. We know they're not necessary,
since they're not present in the existing Fennec Android manifest.
These are strictly workarounds to avoid doing the real work of fixing
the issues. To fix 1), we'd need to migrate all existing users with
homescreen shortcuts to .App. This could be difficult, especially if
partners have deployed packages out of our update control. To fix 2),
we'll need to upgrade our Google Play Services to at least version
9.0.0 and then use the finer-grained AAR dependencies to not build
with the measurement split at all.
MozReview-Commit-ID: 21CaZ2KMeIa
--HG--
extra : rebase_source : c9aff7c414c13843c4e54267c95941fa35bc1001
This has two advantages:
* If the network changes while we are downloading content then we do not continue on an metered network.
* When adding telemetry in one of the next patches then we can report which kind of content we did not
download.
MozReview-Commit-ID: 80QzSRyCArr
--HG--
extra : rebase_source : ff902c57e36cc5eadaef075410635aa07671c353
There's no need to run all other checks if there's nothing scheduled to be downloaded (anymore). In later
patches we want to report error states to our telemetry system and there's no need to report "no network"
errors if we are not going to download anything anyways.
MozReview-Commit-ID: K4bxbM3ptvZ
--HG--
extra : rebase_source : 22c8d9ff3f10e76d25362332232f9eb0e65e0e14
There might be up to 2 Always-show-as-action button in ActionBar.
One for menu-options, one for 3rd-party app action-button, if any.
According to our design spec, the two buttons appearance should be
similiar, therefore now we create them by same method.
MozReview-Commit-ID: GPVteQR3hxr
--HG--
extra : rebase_source : f03b2dcda5864221abe301d1b1ce8f8c1c38752d
Move this change to ActionBarPresenter. Use cross icon as close button
to match design spec.
MozReview-Commit-ID: JgUcKp7p7Bc
--HG--
extra : rebase_source : 8350b2d8684cd967cb7463949017c26db4ef1782
.aidl files can contain interfaces or parcelables. Interfaces should be
compiled through the aidl tool but parcelables should not. Explicitly
list the AIDL interfaces for Fennec, so we only compile the interfaces
but not the parcelables.
Based on what I'm seeing, if you call scrollToPosition and that causes you to
"scroll into view" (remember, scrollToPosition doesn't actually scroll, it just
redraws the new position) one or more positions, then RecyclerView runs the add
animation on all those views "scrolled onto screen", which, for the list view's
slide-in-from-the-right add animation, looks silly (I think). [Caveat:
RecyclerView sometimes keeps one offscreen view ready to go, which doesn't seem
to get the add animation.]
In non open-tab-from-another-app-with-the-tabs-tray-already-open operations this
was never an issue because either those animations are hidden by the panel being
animated into view when the panel opens and we scroll to the selected position
[at least that's my guess], or we only scroll by at most one, as in the case of
a tab close or undo close. But in the
open-a-tab-and-scroll-to-it-while-the-tabs-tray-is-already-open case that we can
get with opening a tab from another app, the add animation runs for however many
tabs "need to be added" between the current position and the new tab; sometimes
the animation still gets hidden if the new tabs get added quickly enough when
fennec reloads [again, my guess], but on my device I always see the animations
if I open a tab in tab queue and then reopen Fennec by hand, whereas on an
emulator I see the animations in additional external-app-open cases as well.
MozReview-Commit-ID: J3x0bBLPNyz
--HG--
extra : rebase_source : 9ee77d395e452e50f958c6c096167704cbe37795
extra : source : f03ab10a14245f2cd8c71130cb677cb8bf1a31db
If another app opens a link in Fennec, and Fennec restores itself in a state
where the tabs tray is already open, we need to scroll to the newly added tab
since it gets added offscreen (not to mention the scroll position restored when
we open is unconstrained (it's whatever the user left it at before they switched
apps)).
This introduces one small change in behavior:
1) Use a gridded tabs tray;
2) Fill more tabs than will fit in the tray;
3) Put more than one tab on the last row;
4) Scroll so that the last row is partially, but not fully, hidden;
5) Close the last tab and then undo the close.
In that case we now scroll the last row fully into view, whereas previously we
maintained the old (partially hidden) scroll position. (If you undo close any
tab other than the last on the final row then you still get the old behavior.)
Note that this fixes the case where the other app adds a *new* tab in Fennec
with the tabs tray open; it's (currently) also possible to open a link in an
already existing tab with the tabs tray open - that's bug 1353226.
MozReview-Commit-ID: BazXFwT0B8v
--HG--
extra : rebase_source : c5fe91793b90f22dfeea0d05fd8730906d0ccdbe
extra : source : 3c5cea45aec424bee4043cd7d362e80aff9a491d
If the activity is restoring, onTabChanged might not be called.
To update title from existing Tab data in onResume.
MozReview-Commit-ID: 3LqQ6HDh7Dc
--HG--
extra : rebase_source : 1dd49658642be420d54d6a8e2d8c33e7658b0f2e
Now we can get toolbar color from intent directly, and the intent will
be stored in `onSavedInstanceState`. Let's get rid of the local
variable.
MozReview-Commit-ID: OsqwgFJctH
--HG--
extra : rebase_source : a5cd688de88de564739481f77fe514bdeffd6c0e
`getIntent()` not always returns the intent whith start this Activity
due to GeckoApp.onCreate reset it. We make a copy here in case of this
activity is destroyed and re-created.
MozReview-Commit-ID: 7TF3b1WdbM2
--HG--
extra : rebase_source : 60bab715166fd01b1fc89ca149e7f5a0f94e6bd1
Promise based MediaDataDecoder expects one response per request, but ICodecCallbacks was not designed that way. onInputExhausted() is called only when there are none or just a few input buffers waiting to be queued, and onOutput() is called as soon as output buffers are available. It means these 2 kinds of events are usually interleaved and hard to align with pending promises. Reporting each input buffer status makes it easier for RemoteDataDecoder to resolve promise properly.
MozReview-Commit-ID: K09txmHTtmX
--HG--
extra : rebase_source : 9ad331c54a24eab6ce5e0195f354afce52247572
Confusion between storeDone() and storeDone(long end) resulted in certain sessions (bookmarks
and form history) not overriding the current method. As a result, their final "flush the queue"
methods weren't being called by the buffering middleware.
This patch removes the storeDone(long end) method, making such confusion a non-issue.
Given that a lot of sessions tend to build up buffers which they need to then flush after a storeDone()
call, passing in a timestamp into that method doesn't make sense. Instead, let's supply a default
implementation in RepositorySession which calls onStoreCompleted(endTimestamp) with current time,
and allow sessions to override this method and own the onStoreCompleted(endTimestamp) call.
MozReview-Commit-ID: 84o7aAL8RPC
--HG--
extra : rebase_source : 41767ad502bd5ad8a0a487235bfdca8cf0d0c927
To observe the difference, use `javap -l`. For example, for
automationRelease and automationDebug built with `./mach gradle clean
app:assembleAutomationRelease app:assembleAutomationDebug`, I see
locally:
$ javap -l objdir-droid/gradle/build/mobile/android/app/intermediates/classes/automation/release/org/mozilla/gecko/home/activitystream/menu/ActivityStreamContextMenu\$1.class
Compiled from "ActivityStreamContextMenu.java"
class org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu$1 extends org.mozilla.gecko.util.UIAsyncTask$WithoutParams<java.lang.Boolean> {
final android.view.MenuItem val$bookmarkItem;
final org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu this$0;
org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu$1(org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu, android.os.Handler, android.view.MenuItem);
LineNumberTable:
line 103: 0
<snip>
}
$ javap -l objdir-droid/gradle/build/mobile/android/app/intermediates/classes/automation/debug/org/mozilla/gecko/home/activitystream/menu/ActivityStreamContextMenu\$1.class
Compiled from "ActivityStreamContextMenu.java"
class org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu$1 extends org.mozilla.gecko.util.UIAsyncTask$WithoutParams<java.lang.Boolean> {
final android.view.MenuItem val$bookmarkItem;
final org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu this$0;
org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu$1(org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu, android.os.Handler, android.view.MenuItem);
LineNumberTable:
line 103: 0
LocalVariableTable:
Start Length Slot Name Signature
0 16 0 this Lorg/mozilla/gecko/home/activitystream/menu/ActivityStreamContextMenu$1;
0 16 1 this$0 Lorg/mozilla/gecko/home/activitystream/menu/ActivityStreamContextMenu;
0 16 2 x0 Landroid/os/Handler;
<snip>
}
MozReview-Commit-ID: 3HmiGkHhowQ
--HG--
extra : rebase_source : c84d8d4b8ac813e49db0c61a30c7098ff2eae3f4
Since we're uploading records atomically, order in which they're processed by the uploader
only matters if we want to do sanity checks on certain types of records. Server might still
preserve some of the order, but for our purposes here it shouldn't matter.
We'd like to ensure that we process the "mobile root" bookmark record along with other folder
records first, so that we increase our chances of avoiding making a failing network request if
that those records' payload is too large.
Sorting by bookmark type achieves this.
MozReview-Commit-ID: KrAs3zepaOk
--HG--
extra : rebase_source : 24f1d3d6aa2ee3b6777dc38abdd1e01aba5213c2
If we try to upload a record whose payload BSO field is larger than the limit specified
by the server, fail that record during BatchingUploader's processing.
Consequently, Synchronizer will fail current sync stage and advance to the next.
Previous behaviour was to essentially rely on the server to fail our POST request,
at which point we'll fail current sync stage. So in a way, this is an optimization to
avoid making network requests which we know will fail.
MozReview-Commit-ID: 5aJRRNoUuXe
--HG--
extra : rebase_source : 18920cfe7b7599be1984c53ebc0c9897c98fb7d9
Also rename Wikipedia Belarusian for consistency
MozReview-Commit-ID: DDtmwrG3sU5
--HG--
extra : rebase_source : 4dcec3ac19f421098f1ed9e9e33a1b13014c745e
