There appears to be a race occurring where InputExhausted callback isn't always called.
The issue could be reproduced prior all those changes, albeit rarely.
The tracking of re-enabling this feature will be done in bug 1336358
MozReview-Commit-ID: 5rPpcCcgNIq
--HG--
extra : rebase_source : bf3513e5ff8d8c72ed7aa505c8fda723a480c243
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
The linked bugs are fixed and we can enable those checks now.
MozReview-Commit-ID: 9UdFH1u9D1I
--HG--
extra : rebase_source : 714e8f3e207612d9d21a69f126ab513f036691a6
This was added for the Android Web App Runtime in Bug 776600. If it
was ever used, it's definitely not now. In addition, fishing the
default orientation from Gecko prefs in a constructor that is
implicitly called from a static singleton initializer is unreliable,
so this probably was never robust. The comments on the ticket say as
much.
MozReview-Commit-ID: E8oz7JsB6oB
--HG--
extra : rebase_source : a77158564f6de73b0673b3720be49d87f89b1377
Fennec has touch support, so enabling
"layout.accessiblecaret.enabled_on_touch" in all.js is sufficient.
MozReview-Commit-ID: 4Aa3g5eqt2F
--HG--
extra : rebase_source : c5fe085fe3d643dcf9f9a3732986954032566837
Since we're Proguarding the automation build now, we shouldn't need to
multiDex anymore -- even in beta.
MozReview-Commit-ID: 6Yc73Vi9Fhd
--HG--
extra : rebase_source : cdfb01a47dc05dfafc4ba67cdb30f86dbd5aa4ec
moz.build achieves better results than Gradle, and I can't fully
explain why that is. At first I thought it was due to
-optimizationpasses, which is 6 for MOZILLA_OFFICIAL; however, it's
not -- I see no change (let alone an improvement), when I set the
number of passes to 1, 6, 10, or 100. I think there are two things at
play. First, moz.build strips debugging information from "libraries",
which are broadly the Google support libraries. I don't think it's
possible to strip debug information in this fine-grained manner using
Gradle. Second, I think the Gradle build might be including more code
than the moz.build configuration (see the follow-up patch removing
multidex support), but I can't determine what's actually different.
After APK compression, I see less than a 50kb regression in APK size
between Gradle and moz.build outputs, which I deem reasonable.
MozReview-Commit-ID: 4q4Zye2wnOF
--HG--
extra : rebase_source : dfc0f983f56ceb5907f9aafcb37d2ac63d50988b
Not really happy about the change but it addresses the problem.
* Loading the list from disk is much faster than parsing the string (2500ms vs. 30-50ms on a Nexus 6P)
* Because of (potential) disk I/O we are required to extract the label asynchronously on a background thread
* We load the list only once and then keep it in memory - like we did before the change.
MozReview-Commit-ID: 9MPGbmIGRnS
--HG--
extra : rebase_source : 8b31f852c6bb90fd57baeb07ba0066421d5a6e46
This allows us the use of VectorDrawable's (which can be created by converting SVG files) in a
limited set of circumstances.
MozReview-Commit-ID: 4n4dXnZYn9W
--HG--
extra : amend_source : 8fbf2579260590a26ecd0112d6fce1055e929bd7
We need to bump the Gradle Deps task, which fetches dependencies, to
include new test dependencies; and use freshly uploaded tooltool
archives (manually uploaded) containing the new test dependencies.
MozReview-Commit-ID: 8bNOVQPHlk6
--HG--
extra : rebase_source : 0c80117fb58e43f9c857027941f0a14f03b97f13
On Windows, the contextmenu event is fired when the finger is lifted after a
long-press. However, there are various bits of code, such as the AccessibleCaret
or potential fixes for bug 1147335, which would benefit from knowing when the
long-press gesture was detected. By moving eMouseLongTap event up we can satisfy
that need. An alternative approach considered was to fire the eMouseLongTap
before the contextmenu on all platforms unconditionally, but that makes it harder
to implement platform-specific text selection behaviour the way we want. In
particular we would have to add an extra message or notification for non-Windows
platforms that initiated text selection if the contextmenu event was not
consumed.
MozReview-Commit-ID: 2lmwxmmGrVD
It's not obvious how to listen to individual errors in most cases, so
we just link to the reports for now. Progress!
MozReview-Commit-ID: 8nGRJdpzZnO
--HG--
extra : rebase_source : e81c9b29cb03c5ba73e793512525b5c9c68ab655
extra : amend_source : ce1e2368d43d37cab8fe41cd7a978342ad3e2ea6
Remove following domains from ua-update.json.in:
auctions.yahoo.co.jp
news.yahoo.co.jp
shopping.yahoo.co.jp
travel.yahoo.co.jp
sports.yahoo.co.jp
mixi.jp
Update bug number inline
