If the main thread has to wait for the session data parsing to finish - which is more likely when you've got many tabs open, meaning a large sessionstore.js file - it does so on "this", i.e. GeckoApp.
The session data parsing itself is done from within a Runnable, so we need to qualify "this" there if we want it to refer to GeckoApp itself, so we can successfully release any waiting threads through notifyAll().
MozReview-Commit-ID: 3LhJsI5rNU3
--HG--
extra : transplant_source : %27%27X%9CTm%A6%88%3F%1B%8Cm%0E4%F1%9D%9B%E5%F2%28
Currently this service does not implement any of the callbacks. However it is
necessary to be detected as an app supporting custom tabs.
MozReview-Commit-ID: Hz99Gp9aQCX
--HG--
extra : rebase_source : b73730f5c4d497e4fef5ed9bab3ae1c50e43de61
This activity doesn't do much yet and just has a layout including a GeckoView.
Some basic behavior from GeckoApp is working though: Context menus, floating
text selection, snackbars.
MozReview-Commit-ID: C6SJeYz609h
--HG--
extra : rebase_source : c65d8657ed795365b81c9bfeda41ac814760db8d
We will need to dispatch Intent objects to different destinations (Browser, Custom Tab and eventually
progressive web apps).
The logic of TabQueueDispatcher is folded into this new activity.
MozReview-Commit-ID: 3P4eIvtAKEW
--HG--
extra : rebase_source : 3d7604a7bdbd2ea80602313e7bc66212a089994b
Build slaves on automation are based on Centos 6, which doesn't have a
recent enough version of libstdc++ for our new requirements. But since
we're building with a recent GCC or clang with its own libstdc++, we do
have such a libstdc++ available somewhere, and the compiler picks it
when invoking the linker.
Problems start happening when we execute some of the built programs
during the build, like host tools (e.g. nsinstall), or target programs
(xpcshell, during packaging). In that case, we need the compiler's
libstdc++ to be used. Which required adding the GCC or clang library
directory to LD_LIBRARY_PATH.
Unconveniently enough, the clang 3.5 tooltool package we're using for
ASAN builds until we can update to at least 3.8 (bug 1278718) doesn't
contain libstdc++.so. So for those builds, pull the GCC package from
tooltool as well, and pick libstdc++ from there.
Before introducing the folder count, the bookmark folder icon
was set as the drawable on a TextView. This actually resulted
in scaling that doesn't preserve the aspect ratio. To reproduce
this in the new ImageView (added when we switched to a two-line
folder layout), we simply need to set the icon size explicitly
and scale to fit the whole area (as opposed to setting two
constraints and fitting while preserving aspect ratio).
The folder/reading-list icons are unaffected as they already
have the expected aspect-ratio, the back-arrow is now scaled
as expected.
MozReview-Commit-ID: Fl5JY3Lznau
--HG--
extra : amend_source : f3ad6cddd9a162953913b3161b9a5ceea6d3e15e
We're now calling setIntent on the background thread. The onTargetSelected callback expects
to be run on the UI thread, and it looks like Android hangs up when we call UI methods
on the background thread. This in turn means the entire background thread gets locked up
(we execute tasks on the background thread sequentially) and no further background runnables
are executed. This breaks anything else requiring use of the background thread, e.g.
favicon generation, search, permissions doorhangers, etc.
MozReview-Commit-ID: CoYUOMqNX0m
--HG--
extra : rebase_source : 84a4dcc8a8aad590f02ba9f8d8b2564922787d17
In this patch, I move the telemetry server preference from app preferences
to per-profile preferences. We never allowed the user to set the preference
so this should cause no issues.
MozReview-Commit-ID: 7D5y58R2ejd
--HG--
extra : rebase_source : 3b4214968cac48150f6a3f873967cb43c7952b1b
Edge case: the admin profile can disable health report upload for themselves
but (I assume) the new profile won't automatically match these settings. While
I'm not sure if this is even possible, it's outside the scope of this bug.
MozReview-Commit-ID: 1SkXhL7B5xb
--HG--
extra : rebase_source : 95540b8b76f7014544022c7cb0880791ac536721
DB access happens deep in the internals of setting a new Intent for our
ActionProvider. Posting this to a background thread here seems to be the simplest
option to ensure correct threading.
MozReview-Commit-ID: 3iS8w5Cxf02
--HG--
extra : rebase_source : 48c90e5fa47a470d3360dbd44dc97111aac5ff3e
It's possible there are more UI-thread DB accesses lurking. To avoid maintenance burden
we should therefore enable this assert only in debug builds - releases will be
unaffected, but we can still notice incorrect DB access during development.
MozReview-Commit-ID: Kgzf1L3WjIE
--HG--
extra : rebase_source : b1f9f01ea746c005a038693aaa5eddb2bb103a2b
