Closed Bug 1215139 Opened 4 years ago Closed 4 years ago

Handle stale native calls after nsWindow destruction

Categories

(Core :: Widget: Android, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla44
Tracking Status
firefox44 --- fixed

People

(Reporter: jchen, Assigned: jchen)

Details

Attachments

(3 files)

I'm noticing some test failures related to native calls arriving from the UI thread after the Gecko nsWindow has been destroyed, when the test is shutting down. We should discard these stale calls instead of trying to complete them, which leads to a null pointer exception.
It's helpful to have a static DisposeNative when disposing of instances
that are still associated with a native object through an null weak
pointer. In that case, we can't call instance methods because the weak
pointer is null, but we can still call static methods.
Attachment #8674426 - Flags: review?(snorp)
This patch adds a separate close() call to nsWindow, and let the
GeckoView decide whether to make that call or not. This lets us use the
static version of disposeNative. If nsWindow is destroyed in the
meantime, we still want to call disposeNative, which would only be
possible using the static version of disposeNative.
Attachment #8674427 - Flags: review?(snorp)
In the period after nsWindow is destroyed, but before disposeNative is
called, we should discard any pending native calls. These calls would
result in exceptions anyways because the nsWindow weak pointer is now
null. After disposeNative is called, any native calls will still result
in exceptions, because in that case, it's Java code's responsibility to
ensure that calls are not made after disposeNative is called.
Attachment #8674429 - Flags: review?(snorp)
Attachment #8674426 - Flags: review?(snorp) → review+
Attachment #8674427 - Flags: review?(snorp) → review+
Attachment #8674429 - Flags: review?(snorp) → review+
You need to log in before you can comment on or make changes to this bug.