Crash in java.lang.NullPointerException: at org.mozilla.gecko.BrowserApp.onAttachedToWindow(BrowserApp.java)

RESOLVED FIXED in Firefox 51

Status

()

Firefox for Android
General
P1
critical
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: sebastian, Assigned: ahunt)

Tracking

({crash})

unspecified
Firefox 51
All
Android
crash
Points:
---

Firefox Tracking Flags

(firefox51 fixed)

Details

(Whiteboard: [TPE-1][MobileAS], crash signature)

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

This bug was filed from the Socorro interface and is 
report bp-574fbead-c16b-4a44-8201-7beb72160803.
=============================================================

> java.lang.NullPointerException
> 	at org.mozilla.gecko.BrowserApp.onAttachedToWindow(BrowserApp.java:975)
> 	at android.support.v7.internal.view.WindowCallbackWrapper.onAttachedToWindow(Unknown Source)
> 	at com.android.internal.policy.impl.PhoneWindow$DecorView.onAttachedToWindow(PhoneWindow.java:2469)
> [..]
(Assignee)

Comment 1

a year ago
Based on the most recent reports, this seems to be happening at:
mDoorhangerOverlay.setVisibility(View.VISIBLE);

I don't see how this would happen unless the layout hasn't been inflated yet, in this case layout inflation happens in GeckoApp.onCreate(). There don't seem to be any guarantees about onAttachedToWindow happening before or after onCreate, if it happens before onCreate, we don't have a layout, and findViewById will return null. (That does however seem implausible, shouldn't onCreate be one of the first calls?)

Looking back at the history: it looks like we wanted to show this doorhanger on all devices except 2.3, but nowadays we show the doorhanger on all supported devices - so we should just set it to visible in the layout, and not flip the visibility in code:
https://hg.mozilla.org/mozilla-central/diff/5a706e4cc1f0/mobile/android/base/java/org/mozilla/gecko/BrowserApp.java#l1.12
Assignee: nobody → ahunt
(Assignee)

Comment 2

a year ago
We still need to set mDoorHangerOverlay for other parts of BrowserApp, but we can findViewById() it during onCreate instead of onAttachedToWindow, which seems more standard / reliable?
Comment hidden (mozreview-request)
(Assignee)

Updated

a year ago
Whiteboard: [TPE-1] → [TPE-1][MobileAS]
Comment on attachment 8782982 [details]
Bug 1293595 - Make doorhanger overlay visible by default, and retrieve it during onCreate

https://reviewboard.mozilla.org/r/72976/#review71352
Attachment #8782982 - Flags: review?(s.kaspari) → review+
Can we land this?
Flags: needinfo?(ahunt)

Comment 6

a year ago
Pushed by ahunt@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/fcdac0d4b2d5
Make doorhanger overlay visible by default, and retrieve it during onCreate r=sebastian
Flags: needinfo?(ahunt)

Comment 7

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/fcdac0d4b2d5
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox51: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 51
Iteration: --- → 1.3
You need to log in before you can comment on or make changes to this bug.