Closed Bug 1078395 Opened 5 years ago Closed 5 years ago

Crash java.lang.RuntimeException: Unable to start activity ComponentInfo{org.mozilla.fennec/org.mozilla.gecko.preferences.GeckoPreferences}: java.lang.NullPointerException

Categories

(Firefox for Android :: General, defect, critical)

35 Branch
All
Android
defect
Not set
critical

Tracking

()

VERIFIED FIXED
Firefox 36
Tracking Status
firefox35 --- verified
firefox36 --- verified
fennec 35+ ---

People

(Reporter: aaronmt, Assigned: rnewman)

References

Details

(Keywords: crash, regression)

Attachments

(1 file)

I/ActivityManager(  764): Displayed org.mozilla.fennec/org.mozilla.gecko.preferences.GeckoPreferences: +165ms
V/GeckoPreferences( 2238): Starting with fragment: org.mozilla.gecko.preferences.GeckoPreferenceFragment, title 2131231026
I/ActivityManager(  764): START u0 {act=android.intent.action.MAIN cmp=org.mozilla.fennec/org.mozilla.gecko.preferences.GeckoPreferences (has extras)} from pid 2238
D/GeckoBrowserProvider( 2238): Expiring history.
D/GeckoBrowserProvider( 2238): Expiring thumbnails.
V/GeckoPreferences( 2238): Checking locale: en_US vs en_US
W/GeckoBatteryManager( 2238): Already started!
V/GeckoNetworkManager( 2238): Registering receiver.
I/ActivityManager(  764): Displayed org.mozilla.fennec/org.mozilla.gecko.preferences.GeckoPreferences: +141ms
V/GeckoPreferences( 2238): Checking locale: en_US vs en_US
W/GeckoBatteryManager( 2238): Already started!
V/GeckoNetworkManager( 2238): Registering receiver.
D/GeckoBrowserProvider( 2238): Expiring history.
D/GeckoBrowserProvider( 2238): Expiring thumbnails.
D/GeckoMemoryMonitor( 2238): onTrimMemory() notification received with level 20
W/ActivityManager(  764): Scheduling restart of crashed service org.mozilla.fennec/org.mozilla.gecko.overlays.service.OverlayActionService in 1000ms
I/WindowState(  764): WIN DEATH: Window{439936d0 u0 org.mozilla.fennec/org.mozilla.gecko.preferences.GeckoPreferences}
I/ActivityManager(  764): Start proc org.mozilla.fennec for activity org.mozilla.fennec/org.mozilla.gecko.preferences.GeckoPreferences: pid=13422 uid=10508 gids={50508, 3003, 1028, 1015}
V/GeckoPreferences(13422): Checking locale: en_US vs en_US
V/GeckoPreferences(13422): Setting activity title to Customize
E/AndroidRuntime(13422): java.lang.RuntimeException: Unable to start activity ComponentInfo{org.mozilla.fennec/org.mozilla.gecko.preferences.GeckoPreferences}: java.lang.NullPointerException
E/AndroidRuntime(13422): 	at org.mozilla.gecko.RestrictedProfiles.getInGuest(RestrictedProfiles.java:45)
E/AndroidRuntime(13422): 	at org.mozilla.gecko.RestrictedProfiles.isAllowed(RestrictedProfiles.java:160)
E/AndroidRuntime(13422): 	at org.mozilla.gecko.RestrictedProfiles.isAllowed(RestrictedProfiles.java:143)
E/AndroidRuntime(13422): 	at org.mozilla.gecko.preferences.GeckoPreferences.setupPreferences(GeckoPreferences.java:721)
E/AndroidRuntime(13422): 	at org.mozilla.gecko.preferences.GeckoPreferences.setupPreferences(GeckoPreferences.java:617)
E/AndroidRuntime(13422): 	at org.mozilla.gecko.preferences.GeckoPreferenceFragment.onCreate(GeckoPreferenceFragment.java:81)
E/AndroidRuntime(13422): 	at org.mozilla.gecko.preferences.GeckoPreferences.onCreate(GeckoPreferences.java:337)
W/ActivityManager(  764):   Force finishing activity org.mozilla.fennec/org.mozilla.gecko.preferences.GeckoPreferences
W/ActivityManager(  764): Activity pause timeout for ActivityRecord{434303c8 u0 org.mozilla.fennec/org.mozilla.gecko.preferences.GeckoPreferences t2 f}
E/WindowManager(  764): Starting window AppWindowToken{43abca48 token=Token{43a23b48 ActivityRecord{434303c8 u0 org.mozilla.fennec/org.mozilla.gecko.preferences.GeckoPreferences t2}}} timed out
W/ActivityManager(  764): Activity destroy timeout for ActivityRecord{434303c8 u0 org.mozilla.fennec/org.mozilla.gecko.preferences.GeckoPreferences t2 f}
Severity: normal → critical
Steps

i) Open preferences
ii) Open Sync
iii) Swipe away Sync
iv) Head back to the browser
tracking-fennec: ? → 35+
Assignee: nobody → rnewman
This bug is straightforward: RestrictedProfiles implicitly assumes that GeckoAppShell has had its GeckoInterface set, which only happens when GeckoApp has started.

Just another lifecycle error.

This will be fixed by moving all profile handling into GeckoProfile, which Wes will finish up in Bug 1077590 and Bug 1080038.

If we do a workaround, it will be one of three things:

* to implement parts of those bugs: to know if we're in Guest Mode we need to get the profile, which involves getting a GeckoProfile instance correctly initialized from our intent args. GeckoPreferences would just reimplement the stuff that GeckoApp does.

* to save some boolean flag in SharedPreferences, caching whether the current profile is a guest session. This is hacky, has invalidation problems, and splits guest mode logic.

* to decide whether we're a guest mode session -- i.e., which kind of GeckoPreferences to show -- in the intent used to launch GeckoPreferences. Android should use the right intent to get back to settings. Again, that has a potential invalidation problem.


The following scenario must be tested:

* Launch a guest session
* Open Settings
* Open Sync (or a Send Tab notification -- it needs to be a separate activity)
* Swipe away
* Return to Settings via the app switcher.

The resulting settings pane should be Guest Mode-specific. If it's not, it means Android is not persisting the intent in the right place for when we're relaunched.

This might be an academic bug -- you can't trigger Sync setup from inside a guest session -- but the issue is still there. It would be worth allowing Sync setup to occur in a guest session for testing purposes in order to exercise this fundamental.
Depends on: 1077590, 1080038
(In reply to Richard Newman [:rnewman] from comment #2)

> * to decide whether we're a guest mode session -- i.e., which kind of
> GeckoPreferences to show -- in the intent used to launch GeckoPreferences.
> Android should use the right intent to get back to settings. Again, that has
> a potential invalidation problem.

Note that this isn't as trivial as it sounds -- RestrictedProfiles is a singleton, initializing itself from GeckoAppShell, so to do this would mean breaking open that encapsulation.

The right fix is to have RestrictedProfiles go to GeckoProfile.
Duplicate of this bug: 1090246
Forgot to post this.

I haven't tested this yet.

The general approach is to allow for explicit initialization of RestrictedProfiles, and to do so from GeckoPreferences.

This will return the wrong answer if GeckoProfile is wrong (e.g., if GeckoProfile is itself waiting for GeckoApp to come along and give it profile data, rather than parsing the launch args from the intent itself).

But it'll be wrong, rather than crashing.
Attachment #8512711 - Flags: review?(wjohnston)
Attachment #8512711 - Flags: review?(wjohnston) → review+
This actually needed a little more (passing contexts into calls, 'cos we don't have that in a few other places), but nothing complicated. Will land when tree opens.
Status: NEW → ASSIGNED
ni for uplift after verification.

Note that you'll still see Bug 979899 with this fix, but you won't get a crash.
Flags: qe-verify?
Flags: needinfo?(rnewman)
Hardware: ARM → All
https://hg.mozilla.org/mozilla-central/rev/aa722c566641
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 36
Comment on attachment 8512711 [details] [diff] [review]
Work around missing profile in RestrictedProfiles. v1

Approval Request Comment
[Feature/regressing bug #]:
  Guest session work (don't know bug).

[User impact if declined]:
  Crash in the particular STR reported in this bug, or certain low-memory situations.

[Describe test coverage new/current, TBPL]:
  Manual.

[Risks and why]: 
  Relatively low risk. This makes some implicit 'inputs' to RestrictedProfiles explicit, and then sets them from the resuming activity. It's a band-aid, but it stops the crash.

[String/UUID change made/needed]:
  None.
Flags: needinfo?(rnewman)
Attachment #8512711 - Flags: approval-mozilla-aurora?
Attachment #8512711 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Needs rebasing for Aurora uplift.
Flags: needinfo?(rnewman)
Aaron, can you please retest this in the latest Nightly to see if you can reproduce it anymore?
Flags: qe-verify?
Flags: qe-verify+
Flags: needinfo?(aaron.train)
QA Contact: aaron.train
This crash is fixed, bug 979899 is what remains as called out above.
Status: RESOLVED → VERIFIED
Flags: needinfo?(aaron.train)
I'm (still) waiting for Aurora to reopen so I can uplift this.
Flags: needinfo?(rnewman)
Verified as fixed in Firefox for Android 35 Beta 1 with Nexus 4 (Android 4.4.4).
No longer depends on: 1077590
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.