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
* 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
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
Jing-wei Wu
Andrzej Hunt
Wes Kocher
James Willcox
Munro Mengjue Chiang
Nick Alexander
Carsten "Tomcat" Book
Matthew Wein
Jan Henning
Sylvestre Ledru
Julian_Chu
John Lin
Jim Chen
Tom Klein
Alastor Wu
Shane Caraveo
Sebastian Hengst
Grigory Kruglov
Ralph Giles
Zibi Braniecki