crash @ java.lang.NullPointerException: at org.mozilla.gecko.AllPagesTab.showSuggestionsOptIn(

RESOLVED FIXED in Firefox 20



Firefox for Android
5 years ago
5 years ago


(Reporter: Robert Kaiser, Assigned: bnicholson)


({crash, regression, topcrash})

20 Branch
Firefox 21
crash, regression, topcrash

Firefox Tracking Flags

(firefox20+ fixed, firefox21 fixed)


(Whiteboard: [native-crash], crash signature)


(1 attachment)



5 years ago
This bug was filed from the Socorro interface and is 
report bp-1f0f359c-b6ae-4d8e-807c-364712130103 .

	at org.mozilla.gecko.AllPagesTab.showSuggestionsOptIn(
	at org.mozilla.gecko.AllPagesTab.setSearchEngines(
	at org.mozilla.gecko.AllPagesTab.access$1500(
	at org.mozilla.gecko.AllPagesTab$
	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 crash reports at

This has been happening on FennecAndroid 20.0a1 Nightly apparently since the 2012-12-19 build, apparently.
Right now it's the #2 crash in yesterday's Nightly data.

Comment 1

5 years ago
Happening at this line:


getSelectedTab() is likely the NPE, and this is probably happening whenever users try to launch the AwesomeScreen after a crash restore (which doesn't use tab stubs).

While we could keep adding null checks around these kinds of statements, I think a better fix would be preventing the AwesomeScreen from opening at all until we have at least one tab in Java. Otherwise, if we're doing a restore, we don't know whether the selected tab will be private or non-private, so the AwesomeScreen UI state could be a mismatch between the selected tab's state.
Just keep in mind that one of the reason we re-wrote in Java was to avoid blocking on Gecko. We _must_ be able to open the Awesomescreen before Gecko is ready.

Comment 3

5 years ago
Private tabs are only restored after OOM kills, so it actually shouldn't be possible with our current implementation for private tabs to be included in a crash restore. We could probably just get away with doing a null check after all, which wouldn't block the AwesomeScreen.

Comment 4

5 years ago
The regression range is:
tracking-fennec: --- → ?
tracking-firefox20: --- → ?
Keywords: regression
Hardware: All → ARM
Whiteboard: [native-crash]
Version: unspecified → Firefox 20


5 years ago
status-firefox20: --- → affected

Comment 5

5 years ago
Created attachment 698896 [details] [diff] [review]
Check for null tab before setting private AwesomeScreen state
Assignee: nobody → bnicholson
Attachment #698896 - Flags: review?(sriram)
Comment on attachment 698896 [details] [diff] [review]
Check for null tab before setting private AwesomeScreen state

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

Looks good to me.
Attachment #698896 - Flags: review?(sriram) → review+

Comment 7

5 years ago
Sorry, I gave bad advice in
Blocks: 821311


5 years ago
tracking-firefox20: ? → +

Comment 9

5 years ago
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 21

Comment 10

5 years ago
It's still 3 top crasher in 20.0a2.

Comment 11

5 years ago
Comment on attachment 698896 [details] [diff] [review]
Check for null tab before setting private AwesomeScreen state

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 821311
User impact if declined: crash whenever opening awesomescreen immediately after session restore
Testing completed (on m-c, etc.): m-c
Risk to taking this patch (and alternatives if risky): very low risk (just adds null check)
String or UUID changes made by this patch: none
Attachment #698896 - Flags: approval-mozilla-aurora?
Comment on attachment 698896 [details] [diff] [review]
Check for null tab before setting private AwesomeScreen state

low risk null check, approved for aurora.
Attachment #698896 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
status-firefox20: affected → fixed
status-firefox21: --- → fixed
tracking-fennec: ? → ---
You need to log in before you can comment on or make changes to this bug.