Closed Bug 870333 Opened 7 years ago Closed 7 years ago

java.lang.NullPointerException: at android.view.inputmethod.BaseInputConnection.isBracketChar(


(Firefox for Android :: Keyboards and IME, defect, critical)

Not set



Firefox 24
Tracking Status
firefox21 --- wontfix
firefox22 --- wontfix
firefox23 --- fixed
firefox24 --- fixed


(Reporter: scoobidiver, Assigned: briancecker)



(Keywords: crash, Whiteboard: [native-crash][lang=java][])

Crash Data


(1 file, 1 obsolete file)

There are one crash in 23.0a1, bp-4c2131bc-1b41-4ec5-85a8-c0ff72130509, 61 in 20.0.1, and 4 in 21.0b6.

	at android.view.inputmethod.BaseInputConnection.isBracketChar(
	at android.view.inputmethod.BaseInputConnection.replaceText(
	at android.view.inputmethod.BaseInputConnection.commitText(
	at org.mozilla.gecko.GeckoInputConnection.commitText(
	at org.mozilla.gecko.GeckoInputConnection.performContextMenuAction(
	at android.os.Handler.dispatchMessage(
	at android.os.Looper.loop(
	at org.mozilla.gecko.GeckoInputConnection$

More reports at:
This is a problem when pasting from an empty clipboard. GeckoAppShell.getClipboardText() is returning null here:

    public boolean performContextMenuAction(int id) {
                commitText(GeckoAppShell.getClipboardText(), 1);
Whiteboard: [native-crash] → [native-crash][lang=java][]
I can take this one. 

Looking at both getClipboardText() and performContextMenuAction(..) there seems to be a couple options. Would it be preferable to make getClipboardText() return some empty string rather than null, or to make the case check the result of getClipboardText(), and fill with an empty string if null? The choice may seem a little irrelevant, but I'm worried that changing the return result of getClipboardText() might break other things that use it.
I think returning "" from getClipboardText() would be safer.

If getClipboardText() always returns a non-null string, then we can replace the callers' null and TextUtils.isEmpty() checks with simpler string.isEmpty() checks.

When you remove TextUtils.isEmpty(), you should also remove `import android.text.TextUtils` if the .java file has no other calls to TextUtils.
Assignee: nobody → briancecker
Attached patch potential patch (obsolete) — Splinter Review
getClipboardText() now returns and empty string instead of null, and callers now use String.isEmpty() tests.
Attachment #748275 - Flags: review?(cpeterson)
Oh, vim also automatically removed some trailing whitespaces, so those are included as well.
Comment on attachment 748275 [details] [diff] [review]
potential patch

Review of attachment 748275 [details] [diff] [review]:

Looking good. Here are some suggestions.

Also, there is an "erorr" typo in the patch description. The description should probably also mention that this fix is related to clipboard text.

::: mobile/android/base/
@@ +1215,5 @@
>              }
>          });
>          try {
>              String ret = sClipboardQueue.take();
> +            return (EMPTY_STRING.equals(ret) ? EMPTY_STRING : ret);

1. Can we just `return sClipboardQueue.take()` here without checking ret or EMPTY_STRING?

2. Can we remove the EMPTY_STRING definition altogether and just use ""? I think I tried that before and accidentally introduced some test failures. I can run your patch on our test servers to see if that is still a problem.

@@ +1220,2 @@
>          } catch (InterruptedException ie) {}
> +        return EMPTY_STRING;

Let's move this `return` inside the `catch` block. I think that would be clearer because an InterruptedException is the only reason we would actually reach this `return`.
Attachment #748275 - Flags: review?(cpeterson) → feedback+
Brian, I ran your patch on the "try" test servers and found a problem:

PROCESS-CRASH | java-exception | java.lang.NoSuchMethodError: java.lang.String.isEmpty at org.mozilla.gecko.BrowserToolbar$3.onCreateContextMenu(

The String.isEmpty() method [1] was added in Gingerbread (Android API Level 9), but we still support Froyo (Android API Level 8). So we need to replace the new String.isEmpty() checks with `TextUtils.isEmpty()`.

Ah so that's why that was being used. What settings did you use for the try server? I ran it on the try server myself last night and didn't get a crash, but I was using limited testing options.
Oh, nevermind I see the try settings in the report.
Attached patch patch_v2Splinter Review
Fixed the things you commented on. Try server results are here:
Attachment #748275 - Attachment is obsolete: true
Attachment #748596 - Flags: feedback?(cpeterson)
Duplicate of this bug: 830825
Comment on attachment 748596 [details] [diff] [review]

Review of attachment 748596 [details] [diff] [review]:

The changes look good, but the tryserver run had some rc1 test failures. I'm rerunning the rc1 tests to see if they are intermittent failures or related to the getClipboardText() changes.
Attachment #748596 - Flags: feedback?(cpeterson) → feedback+

Brian, I landed your patch on mozilla-inbound. I removed the trailing whitespace changes because, even though I agree trailing whitespace is sloppy, I wanted to make the patch smaller so it would be easier to uplift to the Aurora channel. You fixed an old crash that affects all release channels, so I think uplifting it will improve our crash stats. :D
Crash Signature: [@ java.lang.NullPointerException: at android.view.inputmethod.BaseInputConnection.isBracketChar(] → [@ java.lang.NullPointerException: at android.view.inputmethod.BaseInputConnection.isBracketChar(] [@ java.lang.NullPointerException: at org.mozilla.gecko.GeckoEditable.replace(]
Comment on attachment 748596 [details] [diff] [review]

[Approval Request Comment]
Bug caused by (feature/regressing bug #): N/A
User impact if declined: Longstanding (4+ months) but low volume clipboard crash goes unfixed.
Testing completed (on m-c, etc.): m-c
Risk to taking this patch (and alternatives if risky): Low risk because it is adding some null checks.
String or IDL/UUID changes made by this patch: N/A
Attachment #748596 - Flags: review+
Attachment #748596 - Flags: approval-mozilla-aurora?
Attachment #748596 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 24
Brian, thanks for fixing this crash! It's been long-standing problem. <:)
My pleasure :)
You need to log in before you can comment on or make changes to this bug.