Create a new native handle first before deleting any old ones, so we can
be sure the new handle would not have the same value as the old handle,
which can confuse our code.
Differential Revision: https://phabricator.services.mozilla.com/D7107
--HG--
extra : moz-landing-system : lando
When building with the NDK clang, which is the easiest way of building locally,
NDK r17 doesn't work for ARM builds because of a broken clang, and while the
NDK r18-beta fixes that problem, for some people it causes a different set of
issues.
Since NDK r15c doesn't have the ndk-version.h headers, switch to a different
way of bridging the differences that allows people to continue building with
r15c locally.
Differential Revision: https://phabricator.services.mozilla.com/D4471
--HG--
extra : moz-landing-system : lando
Getting a working local build with the system clang might be tricky, while
building with NDK r17 clang is broken (bug 1484723).
NDK r18-beta1 fixes this, but also made all jvalue* method parameters in jni.h
const,so in order to support building with it we need to adjust our relevant
function types, too.
Differential Revision: https://phabricator.services.mozilla.com/D3832
--HG--
extra : moz-landing-system : lando
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : dd000a05bfc2da40c586644d33ca4508fa5330f6
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
This does not remove the directives in widget/ContentCache.cpp as those crash
annotations should be temporary and will be removed once bug 1405832 is fixed.
MozReview-Commit-ID: F0STyYDx8F4
--HG--
extra : rebase_source : 737d3e500e1dd066730660fede52226e832305e6
Remove AndroidJNIWrapper. It was primarily used by JNI.jsm and WebRTC.
Usages in WebRTC are replaced with equivalent uses of JNI templates.
MozReview-Commit-ID: DPSeMOtH2wF
clang complains if we don't have a declaration for Context::sClassRef;
Accessors.h had one, but it's not in the right place to prevent clang
from complaining. Moving it closer to where Context itself is declared
seems like a reasonable thing to do.
Add a way to append app notes to the crash report from Java, so we can
associate additional crash data with the crash.
MozReview-Commit-ID: 6I6pGOWb1sZ
Doing this avoids -Wundefined-var-template warnings with clang. This
warning is mostly harmless (clang is trying to tell you a linker error
might be awaiting you later), but being careful with this might make
using C++ modules easier somewhere down the line.
Use the UI thread's tid for checking if we're on the UI thread in Gecko.
This lets us get rid of `GeckoThread.registerUiThread`, in order to
avoid a race where we check for UI thread before `registerUiThread` is
called.
MozReview-Commit-ID: 11gAWgx4UZo
Right now we throw NullPointerException with the message "Null native
pointer", but we can save the type of the native pointer in the message
to make it easier to categorize and analyze crashes. This patch uses the
__func__ feature to get the name of a particular template parameter
type.
MozReview-Commit-ID: GNWzIy91OD6
The native binding code used `jni::AbstractCall` as the interface
between `ProxyNativeCall` and `DispatchToGeckoPriorityQueue`. However,
we already make use of `nsIRunnable` for dispatching to the XPCOM queue,
so we should just use `nsIRunnable` for the priority queue as well.
MozReview-Commit-ID: KmuNMZZkXX3
This version of the Dynamic Toolbar moves the animation of the toolbar
from the Android UI thread to the compositor thread. All animation for
showing and hiding the toolbar are done with the compositor and a static
snapshot of the real toolbar.
MozReview-Commit-ID: BCe8zpbkWQt
Bug 1344892 - 1. Add option to dispatch to priority queue; r=snorp
For the regular "gecko" option, change to dispatching to the XPCOM event
queue, and add a new "gecko_priority" option that dispatches calls to
the widget event queue. GeckoThread.waitOnGecko is changed to wait on
both the widget queue and the XPCOM queue. nsAppShell::SyncRunEvent is
changed to avoid a possible deadlock condition involving locking
sAppShellLock twice.
Bug 1344892 - 2. Update dispatchTo = "gecko" options; r=snorp
Update some existing dispatchTo = "gecko" options to "gecko_priority",
which typically involve UI events or JNI management calls like
disposeNative. As a rule, disposeNative is dispatched to the queue with
the least priority among the queues that other native members of the
same class dispatch to (i.e. "gecko_priority" if all other native
members dispatch to "gecko_priority", or "gecko" if any native members
dispatch to "gecko").
Bug 1344892 - 3. Update auto-generated bindings; r=me
Bug 1344892 - 1. Add option to dispatch to priority queue; r=snorp
For the regular "gecko" option, change to dispatching to the XPCOM event
queue, and add a new "gecko_priority" option that dispatches calls to
the widget event queue.
Bug 1344892 - 2. Update dispatchTo = "gecko" options; r=snorp
Update some existing dispatchTo = "gecko" options to "gecko_priority",
which typically involve UI events or JNI management calls like
disposeNative.
Bug 1344892 - 3. Update auto-generated bindings; r=me
Bug 1343075 - 1a. Add TextEventDispatcherListener::GetIMEUpdatePreference; r=masayuki
Add a GetIMEUpdatePreference method to TextEventDispatcherListener to
optionally control which IME notifications are received by NotifyIME.
This patch also makes nsBaseWidget forward its GetIMEUpdatePreference
call to the widget's native TextEventDispatcherListener.
Bug 1343075 - 1b. Implement GetIMEUpdatePreference for all TextEventDispatcherListener; r=masayuki
This patch implements GetIMEUpdatePreference for all
TextEventDispatcherListener implementations, by moving previous
implementations of nsIWidget::GetIMEUpdatePreference.
Bug 1343075 - 2. Allow setting a PuppetWidget's native TextEventDispatcherListener; r=masayuki
In PuppetWidget, add getter and setter for the widget's native
TextEventDispatcherListener. This allows overriding of PuppetWidget's
default IME handling. For example, on Android, the PuppetWidget's native
TextEventDispatcherListener will communicate directly with Java IME code
in the main process.
Bug 1343075 - 3. Add AIDL interface for main process; r=rbarker
Add AIDL definition and implementation for an interface for the main
process that child processes can access.
Bug 1343075 - 4. Set Gecko thread JNIEnv for child process; r=snorp
Add a JNIEnv* parameter to XRE_SetAndroidChildFds, which is used to set
the Gecko thread JNIEnv for child processes. XRE_SetAndroidChildFds is
the only Android-specific entry point for child processes, so I think
it's the most logical place to initialize JNI.
Bug 1343075 - 5. Support multiple remote GeckoEditableChild; r=esawin
Support remote GeckoEditableChild instances that are created in the
content processes and connect to the parent process GeckoEditableParent
through binders.
Support having multiple GeckoEditableChild instances in GeckoEditable by
keeping track of which child is currently focused, and only allow
calls to/from the focused child by using access tokens.
Bug 1343075 - 6. Add method to get GeckoEditableParent instance; r=esawin
Add IProcessManager.getEditableParent, which a content process can call
to get the GeckoEditableParent instance that corresponds to a given
content process tab, from the main process.
Bug 1343075 - 7. Support GeckoEditableSupport in content processes; r=esawin
Support creating and running GeckoEditableSupport attached to a
PuppetWidget in content processes.
Because we don't know PuppetWidget's lifetime as well as nsWindow's,
when attached to PuppetWidget, we need to attach/detach our native
object on focus/blur, respectively.
Bug 1343075 - 8. Connect GeckoEditableSupport on PuppetWidget creation; r=esawin
Listen to the "tab-child-created" notification and attach our content
process GeckoEditableSupport to the new PuppetWidget.
Bug 1343075 - 9. Update auto-generated bindings; r=me
Add a Lock function to jni::Ref to lock the referenced object akin to
the synchronized keyword in Java. It returns an AutoLock RAII object
that automatically unlocks the object when going out of scope.
Add a Cast function to jni::Ref to cast a reference to a different type
(e.g. if ref is a jni::Object::Ref referring to a String instance, use |
ref.Cast<jni::String>()->Length() | to get the length of the string).
In MOZ_CHECK_JNI builds, Cast() checks that an instance of the source
class can indeed be cast to the target class.
