The best kind of patch: bulk deletion. This removes two separate but
similar build flags, and an unsupported integration piece. The first
packaged Fennec's resources into an ill-defined GeckoView archive; the
second built on the first to produce an Android ARchive for external
consumption. Neither of these artifacts are supported or have
consumers; in fact, they mislead potential consumers, since they're
known to be broken. The Gradle build work under the --with-gradle
flag, and significant follow-up, is the path forward if Mozilla wants
to invest in packaging GeckoView on Android for external consumption.
That is, rather than hacking together AAR files, we'll use the
well-supported Gradle mechanisms for building and publishing such
libraries.
MozReview-Commit-ID: 4Z1jJ8z0cyJ
--HG--
extra : rebase_source : b8e65f39c286313fe8963bf3832d9b6977ef188f
When reading the previous session file, the RecentTabsAdapter waits for GeckoApp (initialisation runs on the main thread) to have actually moved the previous session file to its correct location (happens from the background thread). Hence we can't do the wait from either of those two threads, because we risk a deadlock otherwise if the RecentTabsAdapter happens to be initialised *before* GeckoApp.
MozReview-Commit-ID: 3GBeReP2iQW
--HG--
extra : transplant_source : %96%DC%08n%F3%CC%0A%9A%B1%E5%22f%19/%EF%A2Q_%E2%0F
chooseCertificate() currently uses a concatenation of the Common Name of the
server cert and the port of the server to allow the user to identify the server
requesting client authentication. Unfortunately, this approach is flawed, since
it doesn't take into account things like SAN entries, which might be very
different from the CN.
Using the hostname instead avoids this problem.
MozReview-Commit-ID: 6XjGCknWNi9
--HG--
extra : transplant_source : k%10N%7B%E8%A4%9B%C9%9A%23Q%D1%99%D2%A3%C0.%2B%7F%A5
I expect the crashes occurred because one of the following:
* the store already existed as a file
* the store was a directory that did not have the appropriate permissions
In the telemetry code, none of the cases above should happen so I assert that
they never do.
If the crashes did occur for these reasons, the user will unfortunately
continue to crash but at least we'll know where our assumptions are going wrong.
I originally intended to write a regression test for listFiles returning null
but it requires the application code to be modified in non-trivial ways (e.g.
accessor methods we might forget to use) so I decided against it.
MozReview-Commit-ID: 9V9H84ehbdO
--HG--
extra : rebase_source : 8290e515c9010bef639e92d1b0420bebe5c7d61c
This changeset will correct the crash we're seeing in the bug.
The docs support that File.listFiles can return null.
MozReview-Commit-ID: FHYGErshhoP
--HG--
extra : rebase_source : 15d0c4a3d283924627f1f97a1f99637244c49c08
This will be used to enable the activity stream panel in place of the HomePager. We are
likely to migrate this to a switchboard flag in future once the new panel becomes
shippable (we are still investigating other distribution mechanisms, so it is entirely
possible this will completely change in future).
MozReview-Commit-ID: I9VSliO0IXE
--HG--
extra : rebase_source : 5c6578e41d7bc4849a7aa4a74c4be6cebc966231
This will permit us to plug in other HomeScreen implementations as needed.
MozReview-Commit-ID: Dvmyk1sdBT6
--HG--
extra : rebase_source : bf8acdf84e35f9b2dbeaa2445121c1cfa6d974e4
This is to help keep the terminology more clear: this container will allow displaying any of our
home screen implementations, and not just the HomePager.
MozReview-Commit-ID: 4kqNipgvQ5I
--HG--
extra : rebase_source : 831090edf10be23baf358d778934e73534b720f2
