Wait to register MediaPlayerManager events until we have a GeckoApp
EventDispatcher, because we only have an EventDispatcher after we create
the GeckoView in onCreate.
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
<input>'s of type checkbox and radio are rendered as native widgets by default
on Desktop, but on Fennec, we fallback to using the built-in, non-native
checkboxes.
The earlier patches in this series made it possible for agent, user and page
stylesheets to make changes to the non-native checkbox and radio input fields.
Unfortunately, some of the default agent styles for those checkbox and radio
elements on Fennec were accidentally setting rules that they shouldn't. That
wasn't a problem before because the inputs couldn't be styled before. Now that
they can, we're failing a bunch of reftests because the inputs look wrong in
certain situations.
For example:
1) We were setting background: var(--form_background) for every radio and
checkbox input. --form_background is just a colour though, and that meant
that the rest of the background styles were being overwritten. This has
been fixed by setting background-color: var(--form_background) instead.
The same also applied to some usage of --form_background_disabled.
2) We were setting border-radius: var(--form_border_radius) on all input
elements, but this was putting rounded corners on the checkbox and
radio inputs as well. This rule has been modified to skip checkbox
and radio inputs.
MozReview-Commit-ID: CnpTRXcCxoY
--HG--
extra : rebase_source : ee688b96270e9b2b3498f18d43f9430048b9b444
This patch does a few things:
1) Change all the in-tree tooltool manifests to contain sccache2 instead of the existing Python sccache
2) Change mozconfig.cache to point at sccache.
3) Lightly tweak the --with-cccache configure option to support sccache, and detect whether we're using ccache or sccache and set an option appropriately.
4) Add a MOZ_SCCACHE_VERBOSE_STATS option, and add a target in the top-level Makefile to make sccache spit out its stats at the end of the build. This is useful to see the cache hits/errors until we get something better.
5) Add MOZ_USING_SCCACHE to the build telemetry. Not that I think it will be immediately useful, but for future use.
MozReview-Commit-ID: 9lrdLwNj5Bm
--HG--
extra : rebase_source : d323457df10d0ee0ac5811940e518d9422a7e070
GeckoView's GeckoEventListener and NativeEventListener are not actually
hooked up to events right now, so it's better to just rip them out until
we figure out a better implementation in the future.
testEventDispatcher used to use nsIAndroidEventDispatcher directly,
either through nsIAndroidBridge or through a window's nsIAndroidView.
Now that Messaging.jsm provides delegate objects for those interfaces,
testEventDispatcher should use Messaging.jsm, so that we are testing
Messaging.jsm as well.
Add a new EventDispatcher interface to Messaging.jsm, and provide means
to access either the global EventDispatcher through
EventDispatcher.instance or a per-window EventDispatcher through
EventDispatcher.for(window). The old Messaging object is retained until
we can convert all existing uses of it in Fennec to use EventDispatcher,
at which point `Messaging` will be made to point to
`EventDispatcher.instance`.
This patch removes support for mozapp iframes, leaving support for
mozbrowser iframes intact. Some of the code has been rewritten in order
to phrase things in terms of mozbrowser only, as opposed to mozbrowser
or app. In some places, code that was only useful with apps has been
completely removed, so that the APIs consumed can also be removed. In
some places where the notion of appId was bleeding out of this API, now
we use NO_APP_ID. Other notions of appId which were restricted to this
API have been removed.
GECKOVIEW_JARS contains two Adjust classes (within constants.jar). These depend on the rest of adjust,
which was previously within FENNEC_JARS. Without the remaining adjust jars being on the classpath during
annotation processing for GECKOVIEW_JARS, we are unable to correctly process those Adjust classes
(i.e. we get a NoClassDefFoundError).
The minimal fix is to process adjust as part of GECKOVIEW_JARS. Because adjust depends on HttpClientLib,
we also need to move the relevant jars into GECKOVIEW_JARS too (sync-thirparty contains HttpClientLib).
This will probably require further untangling, this is a minimal patch to allow beta to actually build.
MozReview-Commit-ID: DLtazTrg3hV
--HG--
extra : rebase_source : ce4ecd7941cb34a9f430ea3da906f7d67775c4d2
This avoids us trying to obtain an invalid cursor position, since
the cursor only maps to highlights items (and not the headers).
MozReview-Commit-ID: 1NtJuvDRa5r
--HG--
extra : rebase_source : e1034428d6f11221b3a58700b6250a215f64565e