The protocol handler is intentionally simple. It works for the entering into the
urlbar case but not a lot else. Included some basic tests.
MozReview-Commit-ID: 4FQ1irdt3Nj
--HG--
extra : rebase_source : 30d9fc7ba2c500f268d282e47d291724d9899ba4
Unfortunately tinting the bookmark star is highly complicated due to the tinting
that NavigationView performs (i.e. we'd likely have to disable NavigationView
tinting, and do manual tinting on every icon - alternatively we could hack
the tint-list to use blue for "checked" items, and set the bookmark item
as checked). Since it's unclear if we even want the star to be blue,
we'll leave it grey (but filled) for now.
MozReview-Commit-ID: DekRZJayKIz
--HG--
extra : rebase_source : 1e3443e5f09c60bd0d7295bc35ecc08ca17b3dab
See https://code.google.com/p/android/issues/detail?id=209558 . On Devices
running Android 4 and below, VectorDrawable's can be corrupted due
to overzealous proguarding. This doesn't appear to have been
fixed in the support library yet, and even if it were fixed we
still wouldn't be able to switch to the most modern support
library without significant work.
MozReview-Commit-ID: 3ByogGygCEd
--HG--
extra : rebase_source : 2adeed63f88ca39a71feec60627fb812b76d3bb4
Previously if we could not compare two icon descriptions we'd always return the "right" one. This does
not create a consistent order if the parameters are flipped. As a result some operations on a TreeSet
can fail (like remove()).
MozReview-Commit-ID: EYPlhzGUEnD
--HG--
extra : rebase_source : f8918c022188401e21a03ac666628cff3e87f317
Also refactor MediaControlService to be test-friendly.
MozReview-Commit-ID: 344cEEuVroG
--HG--
extra : rebase_source : 14042bc3225538f621605b7aadb9d729c01ac62b
When the playing-media changes (ie. in Youtube click another
video when it is alreay playing one), there will be one more
event MEDIA_PLAYING_CHANGE, and the tab is still playing media.
This fix is to handle this situation then update state.
MozReview-Commit-ID: Aje2BBqFZKE
--HG--
extra : rebase_source : f7c8f80c1d49e3a9aef868d11a4cd9d722a5c221
This patch involve State into MediaControlService.
ACTION is behaviour for an intention, and so far we use it for storing
media state. Now involve enum to distinguish State from Action.
So flow becomes: Action happens -> Change State -> UI reflect state
changing.
MozReview-Commit-ID: FBHn02tgVO6
--HG--
extra : rebase_source : e1c57502a13669fad0ee2848c6cff420ebbe064f
Convert the "Tab:*" observers in browser.js, which go through the observer
service, to events that go through GlobalEventDispatcher.
FindHelper.js uses "Tab:Selected" through a lazy loader, but I don't
think FindHelper should listen to "Tab:Selected" at all until it is
being used. THerefore, this patch adds "Tab:Selected" registration to
FindHelper.js itself.
Convert events used in Tabs to GeckoBundle/BundleEventListener events.
All of the events are converted to UI thread events, because a lot of
the listeners modify states in Tab (e.g. through
`Tab.handleLocationChange()`), and those states are later accessed on
the UI thread. We used to modify the states on the Gecko thread, and
then access them on the UI thread, which introduces potential race
conditions. Therefore, I think it's best to convert these events
wholesale to UI thread events to avoid races.
Tabs.notifyListeners now calls the listeners directly if it's already on
the UI thread, instead of posting to the UI thread again. This is meant
as an optimization because the events are now coming in on the UI thread
already.
The "Tab:SelectAndForeground" and "Tab:Select" events are merged into
one "Tab:Select" event, and a "foreground" option is added.
The "Tab:StreamStart" and "Tab:StreamStop" events are merged into one
"Tab:RecordingChange" event, and a "recording" option is added to
indicate starting or stopping.
Make SiteIdentity.update use GeckoBundle, and also simplify the enums
in SiteIdentity, by using Enum.valueOf to get enum values from names,
instead of custom code.
Convert events used in ZoomedView to GeckoBundle/BundleEventListener
events.
"Window:Resize", "Browser:ZoomToPageWidth", and
"Browser:ZoomToRect" listeners are removed because they are not sent
anywhere.
The "Content:LocationChange" listener is merged into the
"Gesture:CloseZoomedView" listener, so that we can leave
"Content:LocationChange" alone for now. Otherwise we would have to
convert the "Content:LocationChange" listener in Tabs as well.
The listeners are changed from global listeners to per-GeckoApp
listeners, because two of the events, "FormAssist:AutoCompleteResult" and
"FormAssist:Hide", are per-GeckoApp events also used by FormAssistPopup.
Because the events are now per-GeckoApp events, they are now registered
from onAttachedToWindow and onDetachedFromWindow.
Convert "FormAssist:*" events in FormAssistPopup to
GeckoBundle/BundleEventListener events. UI thread events are used
because the listener performs operations on the UI thread.
Also convert the "FormAssist:*" observers in browser.js to use
WindowEventDispatcher.
The "FormAssist:AutoComplete" event that goes from Gecko to Java is
renamed to "FormAssist:AutoCompleteResult" to prevent conflict with the
event with the same name that goes from Java to Gecko.
While here, fix abuses of GRE_MILESTONE in moz.build and use
RELEASE_OR_BETA instead.
--HG--
extra : rebase_source : 2a8c6501b0fe3bb603a65d52dda13c609a75b033
This is relevant when a new tab is opened (e.g. through an intent from an external app) just as the user has pressed the Quit button (see bug 1266594), in which case the TabOpen event might reach the session store after Gecko shutdown has already started. If we're still in the preliminary phase and the browser window hasn't yet been closed, we can persist this new tab by collecting the session store data from the browser window once more.
Additionally, we now reset the time of the last backup when clearing the session store data, so the backup file is recreated as soon as possible after a history/tabs sanitisation, especially for users who are cleaning private data on exiting Firefox.
MozReview-Commit-ID: 9BmqrSIUJ42
--HG--
extra : rebase_source : be3c413db16523aac69d8283f36057713c1e9367
System SVG rendering on Android 6.0 seems to be broken for certain VectorDrawable's:
these three icons were being distorted, only on Android 6. Using a different SVG
converter (an online converter, as opposed to the Android Studio converter),
results in the icons being rendered correctly.
MozReview-Commit-ID: 2INnb0clb54
--HG--
extra : rebase_source : 5b3fd9ca7354855c6ee70594b960f0098c98d974
When restoring recently closed tabs during a browsing session, we can just pass the stored parentId as a parameter to addTab and be done with it.
During startup however, we first need to update the parent tab IDs before being able to use it.
At the moment, new tabs are always opened at the end of the tab list and cannot be resorted by the user, so child tabs always appear *after* their parent tabs in the tab list. However because we don't want to rely on this behaviour, we still need to collect a complete mapping between old and new tab IDs first before being able to update the stored parent tab IDs.
Therefore we cannot use the usual method of passing in the parentId during tab creation and have to set it after the fact for this case.
MozReview-Commit-ID: JT5YSkuOSZw
--HG--
extra : rebase_source : 5487f05ed5fd99e12e4f33170688243b36da55e4
As long as the browser remains alive, tab IDs are stable and not reused, however if Firefox is killed and subsequently restarted, the ID sequence is reset and therefore all tabs opened through session restore will most probably be assigned a new tab ID.
Because of this, the stored parent tab IDs will be out of date and have to be refreshed as well so they continue pointing to the correct tab. To achieve this, we therefore create a mapping between old and new tab IDs as they are assigned and then use that to update the stored parent tab IDs, too.
MozReview-Commit-ID: 2GP2H6cUGrx
--HG--
extra : rebase_source : 74adb38f457b9f3cc874bb149b01c9043908d019
Having the previous tab ID in the session store data is required in order to be able to create a mapping between old and new IDs on starting up.
Likewise, the parent ID now needs to be tracked on the Gecko side as well, so it can be saved by the session store and later used when restoring a tab/session.
MozReview-Commit-ID: 3zwoZ9YpZlC
--HG--
extra : rebase_source : 25254f6dbbfbf8291fd1d6dcd194540b15da0cef
Instead of throwing IME exceptions, try to recover from IME errors by
flushing the entire text unless we already tried that before. This
prevents annoying crashes, and deals with known IME bugs that are too
risky to uplift to older releases.
To deal with the Java side trying to send events to Gecko before Gecko
is ready, make a special exception to queue any undispatched events when
Gecko is not ready, so that the events can be redispatched to Gecko
later.
Fix the issue that RemoteManager.init() will be block for 5s when onServiceConnected() is
finished before latch creation.
MozReview-Commit-ID: CYYpLpY7Ns9
--HG--
extra : rebase_source : a1e3612916a4b08790b4798d309e87c7e9121a37
2 birds with 1 stone:
- according to MediaCodec doc, when running in async mode start() must be called after flush() to 'resume receiving input buffers'.
- in JellyBeanAsyncCodec's case, explicit resuming polling input buffers helps Codec decide which buffers are invalid by flush().
MozReview-Commit-ID: Ee5QbppgsVf
--HG--
extra : rebase_source : 52ea8eab4732f3c1e609fcc71673716991e9191d
There's some refactoring needed to make the test work with the new code base.
This will be worked on in bug 1330280.
MozReview-Commit-ID: 7OtZbrZK1A9
--HG--
extra : rebase_source : 8c87d91df04ef0e74fdfbf17951889cd10f498fa
I missed this part of the code when refactoring the icon code in bug 1290014 - because this code
never used our favicon loader but instead accessed the database directly. Now this code is using
the same pipeline we use from Java code and should therefore always load (or generate) an icon.
MozReview-Commit-ID: 9WPvTW1uscI
--HG--
extra : rebase_source : 8f07cb040c0fb7d5b33dbd3ae47ec4a4df8668f0
The referrer intent INSTALL_REFERRER comes after Fennec been installed.
On Android 5+ we might receive the referrer intent and never actually
launch the browser. Attempt to init here to handle that case.
MozReview-Commit-ID: 6kDeqnNT2pS
--HG--
extra : rebase_source : c84cee733760b83de51180b9cfff8744db496575
Convert events used in SharedPreferencesHelper to
GeckoBundle/BundleEventListener events. Gecko thread events are used
because the listeners are expected to be synchronous, especially for the
SharedPreferences:Get event, which also requires a synchronous callback.
Convert the "FilePicker:Show" event used in FilePicker and
testFilePicker to use GeckoBundle/BundleEventListener. UI event is used
because the listener performs Intent operations, which is best for the
UI thread. "FilePicker:Result" notification is removed in favor of
using a callback.
Convert events used in MulticastDNSManager to
GeckoBundle/BundleEventListener events. MulticastDNSManager also sends
observer notifications from Java to Gecko, and that converts nicely to
using the new unified EventDispatcher on both sides. The patch also
hides some logging behind a flag to reduce logcat clutter.
Convert events used in the two JavaAddonManager implementations to
GeckoBundle/BundleEventListener events. Gecko thread events are used to
keep with previous behavior. The external interface for addons is kept
the same (using Bundle/JSONObject as container objects), in order to
preserve compatibility, while the internal implementation is changed to
use GeckoBundle.
In addition to the existing fromJSONObject method, add fromBundle,
toBundle, and toJSONObject methods to GeckoBundle, so a GeckoBundle can
be easily converted to/from Bundle and JSONObject.
Fix code generation for armv7 devices without neon by switching
official builds to the 1.15 beta rust compiler. This fixes the
target generation (and standard library image) to not assume
neon is available, per Google's NDK guidelines.
We expect to update this to 1.15.0 stable before release.
MozReview-Commit-ID: HWJLLGJaUDY
--HG--
extra : rebase_source : 53f00f34f40bb2adb07de27e05019ef0159f5ec8
Fix the issue that RemoteManager.init() will be block for 5s when onServiceConnected() is
finished before latch creation.
MozReview-Commit-ID: CYYpLpY7Ns9
--HG--
extra : rebase_source : cfb6a6aa25d1f274418f879e8a536dbdff664615
2 birds with 1 stone:
- according to MediaCodec doc, when running in async mode start() must be called after flush() to 'resume receiving input buffers'.
- in JellyBeanAsyncCodec's case, explicit resuming polling input buffers helps Codec decide which buffers are invalid by flush().
MozReview-Commit-ID: Ee5QbppgsVf
--HG--
extra : rebase_source : e1593952f0dbbdeabd07e014482bc161315b83de
Experimenting with the shutdown sequence for Part 1 has thrown up a few edge cases that aren't yet properly handled by the session store:
- If Gecko is busy (e.g. loading a resource-intensive page), shutdown of the UI can be delayed for a bit - if the user then manually switches away from Firefox, we might get an application-background message which needs to be ignored if we're already quitting
- Backgrounding of the app while quitting can change the event ordering - the "browser:purge-session-history" notification might arrive *after* we've received "quit-application", in which case we need to flush the session history to disk again after having handled the "purge-session-history" notification.
- clearDisk() should rather delete the session store files synchronously when quitting, because otherwise there's a chance that the delete operation runs *after* the new state has already been written out
MozReview-Commit-ID: LZzGcJHxqhz
--HG--
extra : rebase_source : 9f18b99ae92a8ff0753375ea1e279df08d61640e
When clearing private data on exit, Gecko sends a "Sanitize:ClearHistory" message back to the Java UI, so the latter can clear the history DB if necessary.
For some users, this process is not working, presumably because there is a race condition depending on whether Gecko gets as far as sending that message before the background thread responsible for receiving that message has already shut down/had its listener unregistered, or not.
Therefore, we now wait until the UI's sanitize handlers have been called before starting to shut it down as well.
MozReview-Commit-ID: HoifMYv3spA
--HG--
extra : rebase_source : de4bb656c67104b9d5b1ea83329b77de0688a5d6
The notification bar will be dimmed if in Reader Mode and user scroll
down the page. If not in Reader Mode, make sure the notification bar is
not dimmed.
MozReview-Commit-ID: 87LisdS3nRO
--HG--
extra : rebase_source : c7a6795a2b9b007aeddbee1044f94168a03cd761
Repacks of the upstream builds of rust 1.14.0 stable release.
MozReview-Commit-ID: B5DclOLeBjM
--HG--
extra : rebase_source : 67db55dd62d6177b30ace5008edc680f95c6ed22
Convert the "TextSelection:*" events to use BundleEventListener /
GeckoBundle, in both ActionBarTextSelection.java and
FloatingToolbarTextSelection.java. UI events are used because the
listeners require the UI thread. The "TextSelection:Update" listeners
are removed because the event is no longer sent by ActionBarHandler.
Add overrides for Object methods in GeckoBundle, and redirected them to
the corresponding methods in SimpleArrayMap. For equals, a custom
implementation is used because the equals implementation in
SimpleArrayMap had bugs across different support library versions.
Convert NotificationHelper events to use BundleEventListener and
GeckoBundle. UI events are used to perform notification operations, and
to keep access to mClearableNotifications to the UI thread. Also,
refactor some recently-added code in NotificationHelper.
Convert "Doorhanger:Add" and "Doorhanger:Remove" to bundle events. UI
events are used because the listener performs UI operations. As part of
the refactoring, DoorHangerConfig was refactored to use GeckoBundle, and
due to that change, a lot of other doorhanger-related classes also had
to be refactored to use GeckoBundle.
Repacks of the upstream builds of rust 1.14.0 stable release.
MozReview-Commit-ID: B5DclOLeBjM
--HG--
extra : rebase_source : f56feadb24193f1bec13c93bf0414a50a7de219c
There's a pull request [1] and issue [2] on GitHub tracking the work to land this
in the page-metadata-parser repository. Multiple potential sources for getting a
'provider name' are considered in the linked issue - however they all have
slightly different semantic meanings. Only 'og:site_name' actually has the same
meaning as "provider name". Therefore it is pretty safe to land this part.
[1] https://github.com/mozilla/page-metadata-parser/pull/81
[2] https://github.com/mozilla/page-metadata-parser/issues/79
MozReview-Commit-ID: KQFSLo85JoS
--HG--
extra : rebase_source : ba86e5c3785cda500a1e8f5a8887228c72f6d00f
General concept is to populate the "extras" field with a stringified JSON object
which contains bunch of additional data which, in aggregate, might give insight
into user's actions.
A builder is used in order to make constructing the extras json string easier.
This builder has a concept of a "global state" which lets us easily include some information
with every A-S telemetry ping.
Currently this is used to track whether or not user has a firefox account.
An instance of a builder is passed around, augmented as more information becomes known,
and is materialized into an "extras" string whenever an action occurs and telemetry
event needs to be sent.
MozReview-Commit-ID: GDmxkWChnnA
--HG--
extra : rebase_source : 025d198e16d3a8af8b6e94bd531e916b80f9841a
Unfortunately tinting the bookmark star is highly complicated due to the tinting
that NavigationView performs (i.e. we'd likely have to disable NavigationView
tinting, and do manual tinting on every icon - alternatively we could hack
the tint-list to use blue for "checked" items, and set the bookmark item
as checked). Since it's unclear if we even want the star to be blue,
we'll leave it grey (but filled) for now.
MozReview-Commit-ID: DekRZJayKIz
--HG--
extra : rebase_source : 45c4391fe2756b4aae082f89f8e2f6456cac27a2
Don't go through the VsyncSource Java class to test support for vsync.
Because VsyncSource references symbols from API 16+, Dalvik fails to
load it for API 15 and below. Also make several other changes in
VsyncSource, including removing the unnecessary JNIObject superclass,
and refactoring the instance initialization code, which fixes a possible
race when initializing.
Collect common options used in artifact build tests in a single
mozconfig so they can be set more consistently.
Use this to make unsetting toolchain defines universal in these
tasks, fixing fallout from bug 1283898 which defined CARGO and
RUSTC everywhere, conflicting with --disable-compiler-environment
just like CC and CXX were conflicts in some artifact tasks.
MozReview-Commit-ID: 4SbxByjClQb
--HG--
extra : rebase_source : d8a48fd2192ceb5ece76c827e2243ae784b991cb
The linked bugs are fixed and we can enable those checks now.
MozReview-Commit-ID: 9UdFH1u9D1I
--HG--
extra : rebase_source : 714e8f3e207612d9d21a69f126ab513f036691a6
Doing QI from nsIEditor to nsIEditorIMESupport doesn't make sense because editor should always support all methods and attributes of nsIEditorIMESupport (it does NOT mean that all nsIEditor implementation need to support IME).
This patch moves all of them to nsIEditor for avoiding redundant QIs.
MozReview-Commit-ID: DzIKuGHG4iy
--HG--
extra : rebase_source : cc5e9a6ae4572ebe461d9770ffa5c23d33dc8526
Convert "SearchEngines:Data" to use BundleEventListener/GeckoBundle,
including usages in BrowserSearch, SearchPreferenceCategory,
testAddSearchEngine, testDistribution, etc. Also, convert JSON parsing
code in various classes. UI thread is used because the event listeners
perform various UI operations based on the event data.
Convert "Wifi:Enable" and "Wifi:GetIPAddress" events to GeckoBundle
events. Use the UI thread because we do things like starting activities
and using system services, which are best done on the UI thread.
preferences_general_tablet.xml actually only applies on tablets with enough room
for multiple panes, otherwise preferences_general.xml is used; so the fix here
is necessary to remove the pref on tablets not large enough for multiple
preferences panes.
MozReview-Commit-ID: Ff7VebVYV10
--HG--
extra : rebase_source : fda5012f3edd371de5c431e6c50258de4017f547
The --disable-compile-environment configure option used by
the artifact builds removes all support for toolchains,
including setting paths for them with environment options.
Unset the RUSTC and CARGO vars inherited from mozconfig.rust
in the artifact mozconfigs to accommodate the invalid option
check, just like we do for the CC and CXX options.
MozReview-Commit-ID: IwPetRaIY25
--HG--
extra : rebase_source : 37fb4bf9e69d3082cc0ed6b0013e6363a7e8e8e5
Include mozconfig.rust in the common mozconfig so all jobs
will have the same rust config.
Automation mozconfigs all inherit from mozconfig.common,
so we can include mozconfig.rust there and not need it
anywhere else.
Remove --enable-rust from mozconfig.rust now that it's
the default. We only need the RUSTC and CARGO path
variables so jobs can find the toolchain installed from
the tooltool manifest. Also some automation jobs reject
the configure option if we set it unconditionally.
The --enable-rpath comment is no longer necessary; rust has
been consistently built this way for some time.
MozReview-Commit-ID: 2IeIIIinnPL
--HG--
extra : rebase_source : 79dadcc5ed13f2db312042d755a57698f267e902
Jobs using these additional tooltool manifests need an appropriate
rust toolchain when rust code is enabled.
MozReview-Commit-ID: YM7yjJk3w5
--HG--
extra : rebase_source : d98f3a9c2b1bcba337eedcaa06125ac5fb9dfd40
This commit introduces a special type of a pin, "Activity Stream pin".
It's identified by a fixed position of -1. Activity Stream pins are displayed inline
with top sites, at the very front. They are "non-positioned", as opposed to regular pins
which have a position on Top Sites grid. This approach was selected (as opposed to creating a
new kind of a "non-positioned pins bookmark folder") because it is simpler, does not
involve any migrations or sync changes, and is thus preferred in light of a moving
target that is the current vision for Activity Stream.
Two types of pins, regular ones and Activity Stream pins, are independent of each other.
Due to the fact that pins and bookmarks are almost the same thing, we can only figure our,
based on the underlying queries, the following ahead of time:
- pinned state of a pinned top site item (trivial case)
- pinned state of a non-pinned top site item (trivial case)
- bookmark state of a "bookmarked" hightlight item (trivial case)
- bookmark state of a non-pinned top site item
For all other combinations, states have to be looked up when user opens a context menu for an item.
MozReview-Commit-ID: 3KbOp9S4Pz7
--HG--
extra : rebase_source : a86893a235ee7c6c7d2215b9c8a3b56f986480a9
Since we want to include pinned sites in A-S Top Sites, this removes the "plain top sites"
query which excludes pinned sites.
Maximum number of suggested sites displayed is set so that they will fill out at most two "pages".
MozReview-Commit-ID: 8uynmwiaPkt
--HG--
extra : rebase_source : 763633fca5f9f606a8f6cfd1f4a4332273c34dee
Convert "ClosedTabs:Data" and "Sanitize:Finished" events used in
RecentTabsAdapter and GeckoPreferences from NativeJSObject events to
GeckoBundle events.
