Adding the auto-completion text in the URL bar triggers selection change
notifications on Android 5.0 and above. That led us to think the user
changed the selection, and in turn commit the auto-completion. This
patch makes us ignore this edge case and preserve the auto-completion.
Inform Gecko of the Android process lifecycle by calling
GeckoThread.onPause and onResume, so that Gecko is more likely to be in
a consistent state if Android kills our process.
GeckoThread.waitOnGecko blocks the current thread and waits for previous
events on the Gecko thread to finish executing before continuing. This
is implemented by synchronously running a dummy event on the Gecko
thread. This patch also lets us get rid of sendEventToGeckoSync in
GeckoAppShell.
This bug changed the meaning of profiles with empty names (""). It used
to mean the same thing as a null name, which represents the default
profile. However, the new behavior is that an empty name indicates a
custom profile. So the tests involving empty names are removed from
testGeckoProfile.
Add GeckoThread.initWithProfile that make it easy to target a particular
profile. The method succeeds when GeckoThread has not been initialized
or is already using the specified profile. It fails when the current
profile does not match the specified profile.
Make sure we treat profiles under a custom directory differently. To
simplify things, custom profiles must already exist, and we don't
attempt to cache instances of GeckoProfile containing custom profiles.
Custom profiles are an edge use case (must be passed in via Intent
arguments) so I think it's reasonable to have this behavior change.
Only determine GeckoThread arguments when GeckoThread has not been
started in GeckoApp. Otherwise, if GeckoThread has already started, we
don't need those arguments.
GeckoProfile.get() was reaching into GeckoApp to get and set the current
profile. I think now that GeckoThread is managing the profile, we don't
need that anymore. Also move the GuestSession check to getFromArgs, and
get rid of GeckoApp.getDefaultProfileName and
GeckoProfile.sIsUsingCustomProfile, which are redundant now.
Because Gecko itself can only handle one profile per process, we should
let the GeckoThread singleton manage our GeckoProfile instance on the
Java side, instead of using GeckoApp.
Run checkstyle via:
./mach gradle app:checkstyle
This is intended to be added to automation in bug 1258787 and made more robust
in bug 1261486.
For the addition of future checks, it's worth noting Google's config is
available:
3e4367941c/src/main/resources/google_checks.xml
And this version contains links with descriptions of each of the tasks:
http://checkstyle.sourceforge.net/google_style.html
MozReview-Commit-ID: 5HvtQsyY2JQ
--HG--
extra : rebase_source : ea45bcfb88ec302e9f6e6526d9afdbf2c9c93f01
Since we're now triggering zombification events, we can easily handle resetting the audio playback indicator upon zombifciation by having the tab object listen for the appropriate TabPreZombify event and handle it alongside the normal DOMAudioPlayback events instead of duplicating that functionality within the memory observer.
MozReview-Commit-ID: JSgGyw9g6Lm
--HG--
extra : transplant_source : 1%0D%E5%D2d%E2%23%87%60%96%86m%F1%FA%C8%7E.r%B5%8C
The session store relies on a few event listeners to track the history and life cycle of a tab. Under memory pressure, background tabs are zombified in order to reduce our memory usage. This involves destroying the original tab object and then recreating it as a delay loaded tab.
As the session store is never told about this, it will keep the event listeners for the old tab objects - which have now been destroyed - alive and won't receive any future events for the new tab objects. This means that once a zombification has been triggered, the session history for those tabs will become effectively frozen, so after the next zombification or a session restore, the tab will reload the wrong page.
Therefore this patch introduces two new events which are sent during the tab zombification process and allow the session store to detach its event listeners from the old tab object before it is going to be destroyed and subsequently reattach its listeners to the new tab object.
MozReview-Commit-ID: 6xZtsCNZbQY
--HG--
extra : transplant_source : %7D%BB%D6%BA%D9%F6%B8%0E%7D%F6%0A%26%A0Y%3E%1Dr%7B%F1%C5
Normally we shouldn't get into a situation where aTabData will be null/empty when trying to restore history, but bug 1229259 comment 10 shows that this can somehow still happen, most probably because we zombified a tab before it had any chance to build some session data.
MozReview-Commit-ID: 9Mw55NTiVTP
--HG--
extra : transplant_source : %F5%CE%C5%89%E0%3F%3E%F3%23e%AE%1C%DE%117%B4eE%D0%3B
Up till now, when restoring tabs, the previous session store data was only attached to the tab object where necessary to make delay loaded tabs work. In all other cases, the session store data was left empty and recreated only once page loading had progressed sufficiently far to fire the DOMTitleChanged event. This means that a tab could get lost if the session was saved before this point and Firefox then subsequently killed. In conjunction with bug 1044556, a memory pressure event could also prevent the session store data from being recreated for a tab, because the session store wouldn't recieve any new events for tabs that had been zombified.
Therefore, with this patch we always attach the previous session store data to a freshly restored tab, so it will always be included in a session save even if the save is triggered before tab loading has progressed far enough.
MozReview-Commit-ID: GVupnXwuRDV
--HG--
extra : transplant_source : %AAsbW%B6%10%3A%E9%F1.J%9D%E8W%40%AD%CCkI%1D
Android's Settings.canDrawOverlays() returns true/false for one of the packages with the same
sharedUserId. There's no guarantee that this is actually the current package.
Instead of relying on Settings.canDrawOverlays() we just try to add and remove an invisible
view through WindowManger. If this succeeds then we obviously can draw overlays and if this
fails then we seem to not have the permission.
MozReview-Commit-ID: 1jdrQ7iV3ek
--HG--
extra : rebase_source : cc3161ad659c20c6a6c4fcb1bb1548b4f7a5ca5c
xml/preferences_general.xml isn't used anymore. Replace it with the xml-v11 version
and then remove it from the xml-v11 folder.
MozReview-Commit-ID: G6OHnSZ3cKc
--HG--
extra : rebase_source : b752312e1a2111dbf3895b550fcbc8a92f1ca7aa
A few notes:
* This doesn't accommodate general OMNIJAR_NAME definitions. The
current name (assets/omni.ja) is baked into the product in a few
places, and is very unlikely to change, so we just error out if this
isn't true.
* This makes the package-manifest.in file authoritative for what goes
into assets/, libs/, and the APK root. Previously,
package-manifest.in wrote into assets/ and libs/ but
upload-files-APK.mk also had a convoluted DIST_FILES filtering
process to work through before a file actually made it into the APK.
* This is intentional about repackaging. It simplifies the repackage
step rather than trying to make unpackage-then-repackage the same as
just package. I pretty much never get repackaging correct the first
time; this should help. (I've manually tested it.)
* The ALREADY_SZIPPED during repackaging is subsumed by the previous
check if UNPACKAGE is set. The custom linker expects stored, not
deflated, libraries, so there's some small legwork to accommodate
that in mozjar.
MozReview-Commit-ID: JvVtIUSX685
--HG--
extra : rebase_source : fd8a9cfe3dc364d23b1065995db599f99e676e38
The probes in this patch are annotated with the extra "dom-push-api"
to distinguish from future Fennec-specific push messages. These
probes allow to determine for each user the difference:
{# sites subscribed to} - {# sites unsubscribed from}.
If we assume the same site is not subscribed to multiple times, this
is a good approximation to the total number of sites the user receives
push messages from.
To test manually:
0) Install Fennec and execute |adb shell setprop log.tag.Telemetry DEBUG|.
1) Subscribe to notifications on a site like serviceworke.rs.
Observe a UI Telemetry SAVE event, like:
D/Telemetry( 7109): SendUIEvent: event = save.1 method = service timestamp = 277456 extras = dom-push-api
2) Send a push notification using the sites' interface.
Observe a UI Telemetry PUSH_RECEIVED_MESSAGE event, like:
D/Telemetry( 7109): SendUIEvent: event = action.1 method = service timestamp = 361795 extras = dom-push-api
3) Unsubscribe to notifications by revoking permission using Site
Settings from the URL bar.
Observe a UI Telemetry PUSH_UNSUBSCRIBED_FROM_SITE event, like:
D/Telemetry( 7109): SendUIEvent: event = unsave.1 method = service timestamp = 393600 extras = dom-push-api
MozReview-Commit-ID: IOCwfXFnowA
--HG--
extra : rebase_source : 705440ac545de0bc82ec72951fb646da3fc7d67b
This will be re-implemented without reference to Fennec's Tab/Tabs
data structures.
MozReview-Commit-ID: I12Dlb3ef58
--HG--
extra : rebase_source : 397405a12bd913ac0f837fbc264890786d45ce56
extra : source : ab088eb19b46d9e8dc5551e39aa4a871a4c9ee23
These have no consumer and deserve to be properly reworked.
MozReview-Commit-ID: KmjE44nmLXx
--HG--
extra : rebase_source : 973f13ad0c111413aa73dff233fd771d9f641191
extra : source : dcffecae84b741d837295ad77d0dd9e7ece391eb
The existing code assumes an Activity, not just a Context, but doesn't
statically guarantee it. This patch is safe because it dynamically
type-checks, but it would be better to declare the member to be an
Activity.
MozReview-Commit-ID: 9AigV055I5j
--HG--
extra : rebase_source : e2d273221767735504a93855623961fc171ae413
extra : source : 0476a0d0575b4b07c404eb15bc5a943ae04d0289
GlobalHistory is Fennec-specific: it accesses the Fennec history data
store, and collects Telemetry. This allows other consumers to
implement their own store as appropriate.
MozReview-Commit-ID: 75Uxc5k8V0O
--HG--
extra : rebase_source : 7e25d183045082edaee4295cb95c62100e956c8e
extra : source : 476cdaa0ce08b0808c3892d3d5ee55f701504666
This moves some Fennec-specific home-screen icon manipulations out of
GeckoAppShell. A GeckoView interface can follow.
MozReview-Commit-ID: 7OhRAT9Agdh
--HG--
extra : rebase_source : c5bc8a871a22c5892b320068dea6501ed8884d8e
extra : source : f39f05fa8df3717c57452ac44a16e4a86d9cbd2c
This is just a small simplification to allow us to not depend on
org.mozilla.gecko.R.
MozReview-Commit-ID: TjSYwYyAMS
--HG--
extra : rebase_source : 1a5a256656063b649c4efc2d2cc8c33e476aec88
extra : source : 33e39362305beb355699cbd88cefe4a37354136c
Before this patch, the default policy for the use of SHA1 in certificate
signatures was "allow all" due to compatibility concerns.
After gathering telemetry, we are confident that we can enforce the policy of
"allow for locally-installed roots" (or certificates valid before 2016) without
too much breakage.
MozReview-Commit-ID: 8GxtgdbaS3P
--HG--
extra : rebase_source : d1bed911f2d5d40229ea06556fee0848668e98b6
This was implemented, but never wired up.
I thought long and hard about how to unit test this, and it's quite
difficult. First, we'd have to chose a layer of testing. We could
unit test:
* the JS <-> Java message passing;
* the permission prompts <-> JS interface;
* some interactions with the Service Worker interface.
The first is difficult because none of our current testing emulators
have Google Play Services and GCM enabled, so we'd need to allow to
mock or otherwise fake the GCM registration. Then we'd need to stand
up a mock autopush server (using httpd.js or the Java-side
equivalent), or mock out the autopush client as well. At this point,
we're testing sendMessage. This could be done, but I'd rather slide
this fix in before building out quite a bit of test infrastructure.
(For the record, the Java Push Service state machine is thoroughly
tested with Java unit tests, so I have confidence that the unsubscribe
logic works.)
The second is tested via the PushWebSocket tests, which are now
running on Android. That is, if permissions and the PushService are
interacting badly, we should see it with the existing test suite.
Since PushServiceAndroidGCM is pretty much a pass-through, there's
little value to be added here.
Finally, the third is also tested via the PushWebSocket tests.
There's absolutely nothing GCM specific about the Service Worker
interface to the PushService.
So I'm left manually testing this -- and now we can unsubscribe from
Push messages from sites.
MozReview-Commit-ID: HiRiqasHJ27
--HG--
extra : rebase_source : ce01aa738d583a7200e9dc93ffa38dea9663779c
extra : amend_source : 03fc8a099e83871fa7bfe345168c063b69938d5e
This patch does a couple of things:
* Add a SyncAction for synchronizing the catalog from Kinto
* Add a CleanupAction for removing files no longer needed
* Migrate the data structure of DownloadContentCatalog from a list to a map.
* Move the more complex builder code to its own class: DownloadContentBuilder
* Introduce a switchboard expriment for staged rollout (download-content-catalog-sync)
MozReview-Commit-ID: D733Xx6LxOb
--HG--
rename : mobile/android/tests/background/junit4/src/org/mozilla/gecko/dlc/catalog/TestDownloadContent.java => mobile/android/tests/background/junit4/src/org/mozilla/gecko/dlc/catalog/TestDownloadContentBuilder.java
extra : rebase_source : afd82e4fbc24cf931c6a9198e72adfbf489b025a
Bug 1253278 added support for not zombifying least recently used tabs if they were playing audio. This patch extends this behaviour to also cover the case where we want to zombify *all* background tabs under memory-pressure. Therefore, a tab which is currently playing audio should now never get zombified, which also means that the issue about the audio playing indicator fixed in part 1 is now sidestepped.
MozReview-Commit-ID: LBeEX2KPh2J
--HG--
extra : transplant_source : %297%26%C1%B9%3A%D5hVb%3Ce%FE%05%99%3E%D17%A0%E7
When a tab is zombified, its original tab object is destroyed and replaced by a new copy set for delay loading. This stops audio playback, but doesn't invoke the normal DOMAudioPlaybackStopped event. Because of this, we continue displaying the audio playback indicator in the tabs tray after a zombification, even though the audio itself has stopped.
With this patch, the zombification routine now notifies the UI to stop showing the audio playback indicator if neccessary.
MozReview-Commit-ID: 7oh4d6XP61K
--HG--
extra : transplant_source : %B6%83%F01K%EE%D9%AB%C0%8D3%81Q%81%E2%09mo%C8%1D
This will be re-implemented without reference to Fennec's Tab/Tabs
data structures.
MozReview-Commit-ID: I12Dlb3ef58
--HG--
extra : rebase_source : 853e65fa5fff403defb16d2d95855cf5812dd440
extra : histedit_source : 362571ca464dbd40e4537667643f3cd6b55199f3
These have no consumer and deserve to be properly reworked.
MozReview-Commit-ID: KmjE44nmLXx
--HG--
extra : rebase_source : c2944ad44a0d3eb5b5486ca0afb4548a429dc518
extra : histedit_source : e2b2a2848e64bc0151b8c92071e83aea2e88237f
The existing code assumes an Activity, not just a Context, but doesn't
statically guarantee it. This patch is safe because it dynamically
type-checks, but it would be better to declare the member to be an
Activity.
MozReview-Commit-ID: 9AigV055I5j
--HG--
extra : rebase_source : d2ab14604b27e028d105bb9fd328f703f4d720ad
extra : histedit_source : 14ecb536dcc3719fe9108a1493177b0583bc1c03
GlobalHistory is Fennec-specific: it accesses the Fennec history data
store, and collects Telemetry. This allows other consumers to
implement their own store as appropriate.
MozReview-Commit-ID: 75Uxc5k8V0O
--HG--
extra : rebase_source : 7492eeac06478a64aced9d956940b54d6425b697
extra : histedit_source : ff6e7af17362c316163bc94778ddc8e236df3780
This moves some Fennec-specific home-screen icon manipulations out of
GeckoAppShell. A GeckoView interface can follow.
MozReview-Commit-ID: 7OhRAT9Agdh
--HG--
extra : rebase_source : e09513eb2f922a06b931005eea1151b2365fd990
extra : histedit_source : 82c1feda1c8b504de99e0010bee99b4b264d84c0
This is just a small simplification to allow us to not depend on
org.mozilla.gecko.R.
MozReview-Commit-ID: TjSYwYyAMS
--HG--
extra : rebase_source : 3c107cfec7bfbdbe276823eb3f0c715647485a32
extra : histedit_source : 0e13217f988363f5a68372695860bb56e21a7078
To use this, uncomment the line in geckoview.ddf. Then, after a
build, run
./mach gradle jarLocalDebugClasses
and then
java -cp mobile/android/build/classycle/classycle-1.4.1.jar classycle.dependency.DependencyChecker -mergeInnerClasses -dependencies=@mobile/android/base/geckoview.ddf $OBJDIR/gradle/build/mobile/android/app/intermediates/packaged/local/debug/classes.jar
MozReview-Commit-ID: KYtHXpmCp6x
--HG--
extra : rebase_source : 5b66a5fed9435784960a8f96a682ec3b12bdab3b
Additionally, added WeakReferences to the SEM in its callbacks so we can
GC ASAP if the Activity (and thus the SEM) gets GC'd. This is important
since we hold a reference to Context which can be a rather large object.
Furthermore, I added some related thread annotations where I felt they
were useful.
MozReview-Commit-ID: KaWlw14uOoN
--HG--
extra : rebase_source : 71e8363985179834aaa21b9885a66bd46ae1a361
The callback may be null if setChangeCallback is never called and would cause
a crash.
MozReview-Commit-ID: BNd16Db1A8Q
--HG--
extra : rebase_source : bc54f8eda9a985843358ebd2075edfeedd99b302
The default search engine attribute may be null in the core ping if we haven't
been able to retrieve the value yet. It's unclear when this might be, but the
possibility is in the javadoc of `SearchEngineManager.getEngine`.
MozReview-Commit-ID: IrJB6GyjyTO
--HG--
extra : rebase_source : 7be9fdf01e57b5eba21842707a42662307dc5bee
We want to reuse this code for the main Activity.
MozReview-Commit-ID: BZxIrgmJI2r
--HG--
rename : mobile/android/search/java/org/mozilla/search/providers/SearchEngine.java => mobile/android/base/java/org/mozilla/gecko/search/SearchEngine.java
rename : mobile/android/search/java/org/mozilla/search/providers/SearchEngineManager.java => mobile/android/base/java/org/mozilla/gecko/search/SearchEngineManager.java
extra : rebase_source : 0a4cd7c64ecfbb5270fa2811924b7d22a87741cb
The icon foreground was already the color antlam wanted it to be.
MozReview-Commit-ID: DnxTCMcukfD
--HG--
extra : rebase_source : a520f88aa2efecad0a7c38237deda24b9c0a9ab6
Run checkstyle via:
./mach gradle app:checkstyle
This is intended to be added to automation in bug 1258787.
Concerns with this patch:
1) I don't have a maven-metadata-local.xml. However, I didn't take the
snapshotted version and [1] seems to indicate it's unnecessary for my
particular build.
For the addition of future checks, it's worth noting Google's config is
available:
3e4367941c/src/main/resources/google_checks.xml
And this version contains links with descriptions of each of the tasks:
http://checkstyle.sourceforge.net/google_style.html
[1]: https://maven.apache.org/ref/3.3.3/maven-repository-metadata/
MozReview-Commit-ID: ID3X9ZA27b0
--HG--
extra : rebase_source : ad8d3d5255e366362db5cc19985434e5ab5f9559
extra : histedit_source : b0bc07b572f7010c3f15ee76d52619ff5d76ab52
The checkstyle checks should pass now.
MozReview-Commit-ID: HMRC2D8u8JT
--HG--
extra : rebase_source : ea2c096114dd1830054eae4864ee4426dddda499
extra : histedit_source : bf0fe0b9d7b0b29bea7869c9816214c1f818bae3
AtomicFile is only available for API 17+ so we need to use the framework.
MozReview-Commit-ID: HBrLHvp57Uv
--HG--
extra : rebase_source : 8f42708c9ef8760aec125c4a8955cd2463ae1c51
Note, the effect of this change varies as follows:
(A) New users:
(B) Existing users who have never opened Settings->Advanced:
- Tabs will restore by default
(D) Existing users who have explicitly set the preference to disabled:
(D) Existing users who visited Settings->Advanced, without explicitly opening this preference:
- Tabs will not restore by default
(The preference already has a value set, hence the default has no effect)
MozReview-Commit-ID: DjMeEcYhusj
This is no longer needed - TransitionAwareCursorLoaderCallbacks was the only
consumer - it was removed as it caused race conditions. The ideal future solution
is probably to use recyclerviews to avoid jank, rather than trying to wait for
transitions to happen.
It's also extremely difficult to use this correctly - the
TransitionAwareCursorLoaderCallbacks simply held the cursor that would usually
be swapped in onLoadFinished until transitions have finished (which is incorrect,
since cursors need to be swapped in before onLoadFinished returns). It's hard to imagine
any alternative solutions, short of avoiding loading cursors in the first place (which
isn't too useful, since cursor loading happens in the background, at which point the UI
status is irrelevant), or hacking the CursorLoader to not return from its worker thread
until UI transitions are done (which would require a new thread-safe implementation of
TransitionsTracker), or maybe even hacking Android Framework's AsyncTaskLoader to not run Loader.deliverResult
while transitions are running (which seems awfully brittle and hacky).
MozReview-Commit-ID: 3JWDcznYL4Y
--HG--
extra : rebase_source : 1b4f52d84b21e4d93ebfb2d5c8d633c6ad12cf8e
extra : histedit_source : 2625e74aa08efa085733d3d34c6a2fa8550cf9f9
TransitionAwareCursorLoaderCallbacks is fundamentally flawed: old CursorLoader
cursors _must_ not be used after onLoadFinished has been called. However
we sometimes queue the cursor swapping (which is implemented by subclasses
in onLoadFinishedAfterTransitions) until after transitions have finished.
CursorLoader.deliverResult() closes the old cursor immediately after calling
onLoadFinished (with the new cursor). At this stage the adapter is
still holding onto the old (but now closed cursor), and will crash if it tries
to read this cursor (which can happen if the adapter is still iterating over the
cursor).
Instead we should ensure that we swap the cursors during onLoadFinished - the simplest
way to do this is by eliminating TransitionAwareCursorLoader and using onLoadFinished
the way the Android framework expects.
It's worth noting that TransitionAwareCursorLoader is obsolete: at the time it was added,
home panels were placed in the HomePagerTabStrip, which notified TransitionsTracker about
its transitions. However HomePagerTabStrip no longer exists, hence there's no need
for us to care about these transitions anymore. (The crash seems to happen because we
try to hide the doorhanger every time we receive LOCATION_CHANGE, and each of these starts
a hide transition - even if no doorhanger is shown - hence we often have a transition
in progress every time we show topsites.)
MozReview-Commit-ID: HsytLpHOrp2
--HG--
extra : rebase_source : 0411e017e19bb4393368b175418a41b0129a622b
extra : histedit_source : 19e68ed7f68180122b7514849b5dad4e246784cb
The way set_config is set currently makes it difficult to introspect
moz.configure files to know what configuration items are being set,
because they're hidden in the control flow of functions.
This makes some of the moz.configure more convoluted, but this is why
there are templates, and we can improve the recurring cases afterwards.
This patch removes the JSON flat file based storage and instead uses the
new url_annotations table.
Two mappings will be created in the database:
* Key "feed": website URL -> feed URL
This maps an URL to its feed URL. Multiple URLs can have the same feed
URL. Later this mapping could be used to highlight URLs with feeds or
subscriptions in the UI.
* Key "feed_subscription": feed URL -> Object describing the feed
This is the actual subscription and saves the state of a subscription
linked to the feed URL.
MozReview-Commit-ID: EFVxAwbhT5o
--HG--
extra : rebase_source : deb7bf423b12b06a1bfe619990e57d62c8142eb8
Group multiple updates into one notification and use a different style
for single and multiple updates.
MozReview-Commit-ID: 6PXUEcJ280P
--HG--
extra : rebase_source : f77ec27fa11e13da9d4735353afad803a0b70a17
Some services just do not return any of those headers.
MozReview-Commit-ID: 3LpvZqsHgzJ
--HG--
extra : rebase_source : 31902f4b72fc02fa0f7c018bce218a547f39f1ba
At the same time, we improve things slightly by deriving HOST_CC from CC
in a smarter way, as well as CXX from CC, which we weren't doing
previously.
Many related things are not moved at the same time to keep the patch
somehow "small".
AppCompat capitalizes all text in `Button`s so we have to override
that behavior to maintain the same UI. Ideally, we do this through
`android:buttonStyle` but the place I found the issue doesn't inherit
from that style so we can't and we change the style directly.
There may be issues with other `Button`s, but this is the only one I found.
MozReview-Commit-ID: JQoIlPa9oZD
--HG--
extra : rebase_source : debbb2076a5b339d25dc38c46ccf5e3ce07a0613
extra : source : f774157cf5f423be9a096ed5072b4440d68f4bd1
The pref handler class in GeckoPreferences doesn't need a reference back
to GeckoPreferences, so it's better to make it a static class rather
than a (non-static) anonymous inner class, in order to avoid leaking
the GeckoPreferences instance inadvertently.
To avoid confusion, the patch also renames the class to "PrefCallbacks",
because GeckoPreferences already has an unrelated interface named
"PrefHandler".
HomeConfig.java saved a list of events to be sent later in a batch. This
patch makes it save a pair of strings instead, and the strings are later
used to make calls to GeckoAppShell.
The patch also makes two small optimizations. It makes the queue an
ArrayList instead of a LinkedList to save memory. It also makes copying
the queue a swap instead of a true copy.
On a CLOSED TREE -- Android and automation only.
MozReview-Commit-ID: AU8bt4CDC1V
--HG--
extra : amend_source : ff83d4b0513102abf095949a79bf7f7616bbfa14
extra : histedit_source : 576ce07d4f7d2ea9d1ae1997736cfe59d751be6d
The initial --with-gradle support disabled building the Android test
directories; everything was built from
mobile/android/app/build.gradle. That doesn't declare support files
that need to be packaged for Robocop tests. This patch stops building
instrumentation test APKs, which aren't used in automation under any
circumstance and which aren't packaged when building with Gradle; and
avoids building the Robocop APK by tweaking the Makefile. That gets
support files in place while not using moz.build in place of Gradle.
I would have declared the support files elsewhere, but there are path
requirements that I couldn't make work, so in robocop/ they stay.
MozReview-Commit-ID: KCpXvqzYBsY
--HG--
extra : rebase_source : b99be8fada7787ee473f68265824cca2250c70a1
extra : histedit_source : fa19d3ede51e14707f400ab8527d44f5bf550f85
This also adds a GRADLE_FLAGS environment variable for use in
automation.
Manually tested.
MozReview-Commit-ID: 8nDkqz2VnJn
--HG--
extra : rebase_source : 32626a7dc0c0a6a440e300d92c31670f14319325
extra : amend_source : fe134e25f079851b4c648b53a7a485ee20c15c18
Bug 1242213 removed the entire <activity-alias>. Sadly, users who
added the Firefox icon to their dock (for example, Samsung's Touchwiz
dock) will see the icon disappear when they upgrade, because the
intent filter disappears. (That is, the icon is connected to .App and
action MAIN, not to the package and action MAIN.)
This patch restores the .App <activity-alias> for action MAIN. It
doesn't add the launcher and other categories, which could lead to
multiple launcher icons. New users that add the Firefox icon to their
dock will use .BrowserApp, but sadly we'll need to maintain this alias
essentially forever to support existing dock icons.
MozReview-Commit-ID: 1o9XS5MEs1s
--HG--
extra : rebase_source : 8f4e1321da475bf2dcfca88c5807bf26c940b1c5
extra : amend_source : 3429ff0eaec0edb02e5e47678252bf5a2de74d3f
Michael Comella
Sebastian Kaspari
Carsten "Tomcat" Book
Kyle Huey
Jim Chen
Nick Alexander
Margaret Leibovic
Alexandre Poirot
Ryan VanderMeulen
Jeff Muizelaar
Jan Henning
Dinesh Polathula
Randall Barker
Wes Kocher
Mike Shal
James Willcox
Eugen Sawin
Mouaad
Aleksander
Chenxia Liu
Katie Broida
David Keeler
Eitan Isaacson
Matthew Wein
Seth Fowler
Mark Capella
Andrzej Hunt
Andrzej Hunt
Mike Hommey
Geoff Brown
Sebastian Hengst
Gijs Kruitbosch
Shatur
Maurya Talisetti
Narek Babajanyan