The experiment in Switchboard is "full-bookmark-management", and it's enabled for 100% of the Nightly audience.
MozReview-Commit-ID: EhA0BcouPPn
--HG--
extra : rebase_source : beeddc921a089606d8a752b75c3a0280a1803972
Every single caller of getAppEventDispatcher() and getEventDispatcher()
assumes a non-null return value, so let's make sure we're actually returning
a non-null value. This commit doesn't effectively change runtime behaviour
(any previously NPE crashes will now result in a crash due to IllegalStateException),
however we now at least have an obvious error message in that situation.
In reality, no code should run before onCreate(), so this should realistically
never happen - but we should still check to ensure that is the case.
(This removes 28 infer NULL_DEREFERENCE warnings.)
MozReview-Commit-ID: GhzwKWfkAbD
--HG--
extra : rebase_source : f6b13f590b437ebb63e502f774a70164054ecf7e
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
On some devices / os combinations, enabling adaptive playback causes decoded frame unusable.
It may cause the decode frame to be black and white or return tiled frames.
So we should do the blacklist according to the report.
MozReview-Commit-ID: j3PZXTtkXG
--HG--
extra : transplant_source : %B0%13%F9%D8i%06d%7B%E3%D7%B1%95%BCCV%DF%D4%EF%93%E7
To make sure these functions can be used in robocop test.
MozReview-Commit-ID: KPAKOrg5Ows
--HG--
extra : rebase_source : cb21f8dc19fb9368f789d46d38ed46ad2b916df1
Add check for media notification's small icon, title and content text.
MozReview-Commit-ID: AOhag8gQVqs
--HG--
extra : rebase_source : 95ba0378056c997855af0d0dceffed7dbdb90f03
It's easy to know what test tasks we'll run in this test.
MozReview-Commit-ID: DdtFp4pOXlC
--HG--
extra : rebase_source : 3618c4fe0037b16fb6e8727c1523d9121732a61a
Create new test class for reducing the redundant code and can provide more
flexibility for adding new related test in the future.
MozReview-Commit-ID: 2f3O8vfHo12
--HG--
extra : rebase_source : 6b503816d9ac75d9269d8f81b2dad300bf1e9702
Notify observer might cause the method (notifyStoppedPlaying) is called by C++ side,
and we should change our internal state before calling the method.
MozReview-Commit-ID: 5xNXhGmAIrR
--HG--
extra : rebase_source : c13943e717fe28b24a1bc6a83c9e6ac18b37eb9d
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
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
This patch affects all grided tabs panel layouts: tablets, phones in landscape
mode, and phones in portrait mode with the "Compact tabs" setting on.
MozReview-Commit-ID: 5cqVJA57ARu
--HG--
extra : rebase_source : c71d4e028bcef921f6a2725d14aaf27940d87f5e
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 : c45694814145946425031064cf59d3b863d3bde4
__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.
Once user click "Open in browser" from menu, we are going to open a tab
in full browser, and close this activity. Therefore we won't have two
tabs which confuse user.
MozReview-Commit-ID: Co9gAdWweFX
--HG--
extra : rebase_source : 2f8f783783491ef480ca5266268d9d3b21bcab23
I can't remove the throbber.png itself because about:performance is
using it.
MozReview-Commit-ID: 6xqAqROptG4
--HG--
extra : rebase_source : 817981ed534800d646ce4decf3e69fff96e3e9fc
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
Jing-wei Wu
Andrzej Hunt
Wes Kocher
James Willcox
Munro Mengjue Chiang
Nick Alexander
Tom Klein
Jan Henning
Carsten "Tomcat" Book
Matthew Wein
Sylvestre Ledru
Julian_Chu
John Lin
Jim Chen
Alastor Wu
Shane Caraveo
Sebastian Hengst
Grigory Kruglov
Ralph Giles
Michael Kaply
maliu
Zibi Braniecki
Nevin Chen
Florian Queze
Kris Maglione
Ted Mielczarek
Randall Barker
Honza Bambas
James Cheng
Iris Hsiao
Eugen Sawin
Francesco Lodolo (:flod)
Sebastian Kaspari
Dylan Roeh
Geoff Brown
Joel Maher
L10n Bumper Bot
Delphine Lebédel
Nitish
nechen
Dale Harvey
Phil Ringnalda
Tomislav Jovanovic
Ehsan Akhgari
Jim Porter
Ryan VanderMeulen
Edouard Oger
Valentin Gosu
brainbreaker
Timothy Guan-tin Chien