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
Bug 1307820 - 1a. Move GeckoApp EventDispatcher to GeckoView; r=snorp
Make it a GeckoView-specific EventDispatcher instead of
GeckoApp-specific, so that GeckoView consumers can benefit from a
per-view EventDispatcher. In addition, a few events like Gecko:Ready are
moved back to the global EventDispatcher because that makes more sense.
Bug 1307820 - 1b. Don't use GeckoApp EventDispatcher during inflation; r=snorp
During layout inflation, we don't yet have GeckoView and therefore the
GeckoView EventDispatcher, so we should not register events until later,
typically during onAttachedToWindow.
Bug 1307820 - 2. Introduce GeckoBundle; r=snorp
The Android Bundle class has several disadvantages when used for holding
structured data from JS.
The most obvious one is the differentiation between int and double,
which doesn't exist in JS. So when a JS number is converted to either a
Bundle int or double, we run the risk of making a wrong conversion,
resulting in a type mismatch exception when Java uses the Bundle. This
extends to number arrays from JS.
There is one more gotcha when using arrays. When we receive an empty
array from JS, there is no way for us to determine the type of the
array, because even empty arrays in Java have types. We are forced to
pick an arbitrary type like boolean[], which can easily result in a type
mismatch exception when using the array on the Java side.
In addition, Bundle is fairly cumbersome, and we cannot access the inner
structures of Bundle from Java or JNI, making it harder to use.
With these factors in mind, this patch introduces GeckoBundle as a
better choice for Gecko/Java communication. It is almost fully
API-compatible with the Android Bundle; only the Bundle array methods
are different. It resolves the numbers problem by performing conversions
if necessary, and it is a lot more lightweight than Bundle.
Bug 1307820 - 3. Convert BundleEventListener to use GeckoBundle; r=snorp
Convert BundleEventListener from using Bundle to using GeckoBundle.
Because NativeJSContainer still only supports Bundle, we do an extra
conversion when sending Bundle messages, but eventually, as we eliminate
the use of NativeJSContainer, that will go away as well.
Bug 1307820 - 4. Introduce EventDispatcher interfaces; r=snorp
Introduce several new XPCOM interfaces for the new EventDispatcher API,
these interfaces are mostly mirrored after their Java counterparts.
* nsIAndroidEventDispatcher is the main interface for
registering/unregistering listeners and for dispatching events from
JS/C++.
* nsIAndroidEventListener is the interface that JS/C++ clients implement
to receive events.
* nsIAndroidEventCallback is the interface that JS/C++ clients implement
to receive responses from dispatched events.
* nsIAndroidView is the new interface that every window receives
that is specific to the window/GeckoView pair. It is passed to chrome
scripts through window arguments.
Bug 1307820 - 5. Remove EventDispatcher references from gfx code; r=snorp
EventDispatcher was used for JPZC, but NPZC doesn't use it anymore.
Bug 1307820 - 6. General JNI template improvements; r=snorp
This patch includes several improvements to the JNI templates.
* Context::RawClassRef is removed to avoid misuse, as Context::ClassRef
should be used instead.
* Fix a compile error, in certain usages, in the DisposeNative overload
in NativeStub.
* Add Ref::IsInstanceOf and Context::IsInstanceOf to mirror the
JNIEnv::IsInstanceOf call.
* Add Ref::operator* and Context::operator* to provide an easy way to
get a Context object.
* Add built-in declarations for boxed Java objects (e.g. Boolean,
Integer, etc).
* Add ObjectArray::New for creating new object arrays of specific types.
* Add lvalue qualifiers to LocalRef::operator= and GlobalRef::operator=,
to prevent accidentally assigning to rvalues. (e.g.
`objectArray->GetElement(0) = newObject;`, which won't work as intended.)
Bug 1307820 - 7. Support ownership through RefPtr for native JNI objects; r=snorp
In addition to direct ownership and weak pointer ownership, add a third
ownership model where a native JNI object owns a RefPtr that holds a
strong reference to the actual C++ object. This ownership model works
well with ref-counted objects such as XPCOM objects, and is activated
through the presence of public members AddRef() and Release() in the C++
object.
Bug 1307820 - 8. Implement Gecko-side EventDispatcher; r=snorp
Add a skeletal implementation of EventDispatcher on the Gecko side.
Each widget::EventDispatcher will be associated with a Java
EventDispatcher, so events can be dispatched from Gecko to Java and vice
versa. AndroidBridge and nsWindow will implement
nsIAndroidEventDispatcher through widget::EventDispatcher.
Other patches will add more complete functionality such as
GeckoBundle/JSObject translation and support for callbacks.
Bug 1307820 - 9. Implement dispatching between Gecko/Java; r=snorp
Implement translation between JSObject and GeckoBundle, and use that for
dispatching events from Gecko to Java and vice versa.
Bug 1307820 - 10. Implement callback support; r=snorp
Implement callback support for both Gecko-to-Java events and
Java-to-Gecko events.
For Gecko-to-Java, we translate nsIAndroidEventCallback to a Java
EventCallback through NativeCallbackDelegate and pass it to the Java
listener.
For Java-to-Gecko, we translate EventCallback to a
nsIAndroidEventCallback through JavaCallbackDelegate and pass it to the
Gecko listener. There is another JavaCallbackDelegate on the Java side
that redirects the callback to a particular thread. For example, if the
event was dispatched from the UI thread, we make sure the callback
happens on the UI thread as well.
Bug 1307820 - 11. Add BundleEventListener support for Gecko thread; r=snorp
Add support for BundleEventListener on the Gecko thread, so that we can
use it to replace any existing GeckoEventListener or NativeEventListener
implementations that require the listener be run synchronously on the
Gecko thread.
Bug 1307820 - 12. Add global EventDispatcher in AndroidBridge; r=snorp
Add an instance of EventDispatcher to AndroidBridge to act as a global
event dispatcher.
Bug 1307820 - 13. Add per-nsWindow EventDispatcher; r=snorp
Add an instance of EventDispatcher to each nsWindow through an
AndroidView object, which implements nsIAndroidView. The nsIAndroidView
is passed to the chrome script through the window argument when opening
the window.
Bug 1307820 - 14. Update auto-generated bindings; r=me
Bug 1307820 - 15. Update testEventDispatcher; r=snorp
Update testEventDispatcher to include new functionalities in
EventDisptcher.
* Add tests for dispatching events to UI/background thread through
nsIAndroidEventDispatcher::dispatch.
* Add tests for dispatching events to UI/background thread through
EventDispatcher.dispatch.
* Add tests for dispatching events to Gecko thread through
EventDispatcher.dispatch.
Each kind of test exercises both the global EventDispatcher through
EventDispatcher.getInstance() and the per-GeckoView EventDispatcher
through GeckoApp.getEventDispatcher().
We use a Maven repository and the (misleadingly named!) uploadArchives
task because this is the best way to make Android Studio download and
recognize the Javadoc and sources. With this, it's automatic; with a
single AAR file, it's a nightmare of point-and-click configuration.
This patch does a bunch of Gradle hacking to make -javadoc and
-sources JARs; there's nothing special or particularly likely to break
here.
This patch also adds Proguard declarations to the :geckoview library
project. That involves moving a good part of the Proguard
configuration into mobile/android/geckoview. (I also expand upon the
existing configuration.) This should be only a re-arrangement, and
the resulting file is included in the original, so nothing should be
changed.
MozReview-Commit-ID: BGNW1v92J0k
--HG--
extra : rebase_source : 94633d27e8ae6bafa3d6823996355c22d2e2e6eb
getSelectedTab() specifies that it can return null "if we're doing a
session restore after a crash and Gecko isn't ready yet". This seems
to occasionally be happening, resulting in crashes.
(What isn't clear is why this would be happening more regularly in 51,
it's possible some completely unrelated changes are either making
the rendering of TopSites faster, causing this call to be made earlier,
or session restore has simply gotten slower. We have also had a
crash spike recently due to library loading issues, which would
likely further exacerbate the whole issue.)
MozReview-Commit-ID: GLFOoXFrAkj
--HG--
extra : rebase_source : e47922ad2b0aa9dc795f0efc1ea477a9805bd4f1
The circular ripple is only available on API >= 21. We can fallback to a different solution
for older devices, see following patch.
MozReview-Commit-ID: C0aBqsKsuZ5
--HG--
extra : rebase_source : ae5139daca4a61c1dfe78bdca7d686494d36d482
extra : source : 34e9726d1c21fa1d998f8469175e8b91d849b7e7
The ripple added using selectableItemBackgroundBorderless is scaled to the actual View area.
By rearranging our margins+padding we are able to make the empty space around the menu button
part of its padding, which results in a more naturally sized ripple. Without this
patch the circular ripple is tiny and looks odd.
MozReview-Commit-ID: 3jHWiubMtDD
--HG--
extra : rebase_source : 1c5a5f81db1c7eff45145a91b37197eef0a118f4
extra : source : 60235315c78c56655049c6e552a9c25085f1a4e4
This allows artifact builds to load the new compressed native libraries correctly,
without requiring build config changes.
MozReview-Commit-ID: 3xZzoV3wFda
--HG--
extra : rebase_source : 5fffe02efc38af9024ca72654153deed3c4ef757
These were leftover from when the toppanel was a RelativeLayout. (Leaving
these also causes lint to complain, the paramters are however ignored
by LinearLayout.)
MozReview-Commit-ID: HTZvo2fnqVj
--HG--
extra : rebase_source : 2872d44ab56f938f1eb39acc3d7b2825eafb0170
By default, a TextView within e.g. a RelativeLayout will be used as the description for
the entire layout. I.e. traversal of the RecyclerView would begin with the Highlights title
being read, and the entire toppanel (i.e. TopSites + the Highlights title) being focused,
followed by traversing the TopSites pager. Instead we want to make sure TopSites are
traversed _before_ getting to the highlights title.
MozReview-Commit-ID: IIrts6vGouK
--HG--
extra : rebase_source : 2c16b46f1a732d7da9375e50b9d8f55a27c1385f
Setting the max height is completely arbitrary, and largely unnecessary - I think it's better
to let the bottom automatically handle this until we know more about how the bottom sheet
is perceived by real users.
The peek height is similarly arbitrary - we'll probably want to discuss a good default height
algorithm with UX, but setting an arbitrary hardcoded value seems wrong, especially since
it doesn't behave well in landscape mode. BottomSheetDialog already does an acceptable
job of finding a default peek height.
MozReview-Commit-ID: LyAYzcytR6H
--HG--
extra : rebase_source : a40a6be42e57e14bb4ba1078323f666d32fe21ed
This is in preparation for having a popup menu on tablets.
MozReview-Commit-ID: 14thIuhRkgB
--HG--
rename : mobile/android/base/resources/layout/activity_stream_contextmenu_layout.xml => mobile/android/base/resources/layout/activity_stream_contextmenu_bottomsheet.xml
extra : rebase_source : 83fb9e517bcbe830e84f9f3613525d990aebef54
extra : source : 49ebe98a0ce759da2554834355a2abd1a9b7e796
Fix a mistake in calculating the correct offset for one of the
replacement steps, which caused the IndexOutOfBoundsException. The old
code used `oldEnd` for the second text replacement without taking into
account the offset change as a result of the first text replacement that
was already performed. The new code correctly takes the offset, `delta`,
into account.
Ehsan Akhgari
Wes Kocher
Kris Maglione
Dylan Roeh
Andrzej Hunt
Tom Klein
Carsten "Tomcat" Book
Michelangelo De Simone
KuoE0
Justin Wood
Boris Zbarsky
Randall Barker
James Willcox
Jim Chen
Nick Alexander
Andrea Marchesini
Chris AtLee
maliu
James Cheng
Phil Ringnalda