Closed Bug 828480 Opened 10 years ago Closed 10 years ago

java.lang.NullPointerException: at org.mozilla.gecko.AllPagesTab.setSuggestionsEnabled(


(Firefox for Android Graveyard :: General, defect)

18 Branch
Not set


(firefox18 wontfix, firefox19 fixed, firefox20 fixed, firefox21 fixed)

Firefox 21
Tracking Status
firefox18 --- wontfix
firefox19 --- fixed
firefox20 --- fixed
firefox21 --- fixed


(Reporter: scoobidiver, Assigned: bnicholson)



(Keywords: crash, Whiteboard: [native-crash][startupcrash])

Crash Data


(1 file)

This bug tracks crashes not fixed by bug 816902.

Here is a crash report :bp-a3b1db88-e2be-452d-8667-0e8cf2130109.

	at org.mozilla.gecko.AllPagesTab.setSuggestionsEnabled(
	at org.mozilla.gecko.AllPagesTab.access$900(
	at org.mozilla.gecko.AllPagesTab$5.onClick(
	at android.view.View.performClick(
	at android.view.View$
	at android.os.Handler.handleCallback(
	at android.os.Handler.dispatchMessage(
	at android.os.Looper.loop(
	at java.lang.reflect.Method.invokeNative(Native Method)
	at java.lang.reflect.Method.invoke(
	at dalvik.system.NativeStart.main(Native Method)

More reports at:
Assignee: nobody → bnicholson
Bug 816902 immediately removed these listeners to prevent them from being triggered multiple times here:

The only place we set mSuggestionsPrompt to null is here:

That means setSuggestionsEnabled() was already called prior to the NPE, which means that multiple onClick() calls are still possible with the current implementation. I assume the click event isn't synchronously dispatched, so users could still queue up multiple click events before onClick() is first called. I found this same issue described here:

An easy fix would be to add a null check for mSuggestionsPrompt to the beginning of setSuggestionsEnabled(), but I'd be concerned that the Runnable at could potentially be executed after the second call to setSuggestionsEnabled() has already begun (which would cause a NPE for mSuggestionsPrompt somewhere later in the method). A fix that should work would be to create a class-level boolean that's toggled on the first call, but I hate creating a boolean for something so trivial...
Blocks: 816902
This just adds a null check to the beginning of setSuggestionsEnabled(). We can look into other fixes if we still have crashes as speculated in comment 1.
Attachment #702055 - Flags: review?(mark.finkle)
Attachment #702055 - Flags: review?(mark.finkle) → review+
Comment on attachment 702055 [details] [diff] [review]
Add null check for mSuggestionsOptInPrompt

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 769145
User impact if declined: crashes if suggestions prompt response is clicked repeatedly
Testing completed (on m-c, etc.): just landed m-i
Risk to taking this patch (and alternatives if risky): very low risk - just adds a null pointer check
String or UUID changes made by this patch: none
Attachment #702055 - Flags: approval-mozilla-beta?
Attachment #702055 - Flags: approval-mozilla-aurora?
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 21
Comment on attachment 702055 [details] [diff] [review]
Add null check for mSuggestionsOptInPrompt

Mobile only null check, good for b3 and Aurora.
Attachment #702055 - Flags: approval-mozilla-beta?
Attachment #702055 - Flags: approval-mozilla-beta+
Attachment #702055 - Flags: approval-mozilla-aurora?
Attachment #702055 - Flags: approval-mozilla-aurora+
(Also, this is in my queue to land on Aurora once it reopens)
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.