964861 - crash in java.lang.NullPointerException: at org.mozilla.gecko.toolbar.ToolbarDisplayLayout.updateFromTab(ToolbarDisplayLayout.java)

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Aaron Train [:aaronmt]]

This bug was filed from the Socorro interface and is 
report bp-c31482de-7959-44ec-a98b-a75b82140126.
=============================================================

java.lang.NullPointerException
	at org.mozilla.gecko.toolbar.ToolbarDisplayLayout.updateFromTab(ToolbarDisplayLayout.java:267)
	at org.mozilla.gecko.toolbar.BrowserToolbar.onTabChanged(BrowserToolbar.java:531)
	at org.mozilla.gecko.Tabs$5.run(Tabs.java:595)

Comment 1

[Ashish Namdev]

i also had this crash 8 times contentiously.

ID  : e79a3858-5377-4f81-916b-45b072140131

Comment 2

[Ashish Namdev]

Setps to Reproduce this Issue 

1. Launch Nightly.
2. Go To Menu > Settings
3. Tap on mozilla
4. Tap on About Nightly.

Actual Result  : 

Crashed !!!!!!!!!

Expected Result  :

About Nightly Page should open.


Version  : Nightly 29.0a1 (2014-01-30)

Observations  :

1 - crash - Restart Nightly after crash reporter -> About Nightly Open
2 - crash - Restart Nightly after crash reporter -> About Nightly Open
3 - closed - Nightly closed  - Crash Reporter Not launched.  
4 - crash - Restart Nightly after crash reporter -> About Nightly Open
5 - crash - Restart Nightly after crash reporter -> About Nightly Open
6 - crash - Restart Nightly after crash reporter -> About Nightly Open
7 - crash - Restart Nightly after crash reporter -> About Nightly Open.
8 - closed - Nightly closed  - Crash Reporter Not launched. 
9 - crash - Restart Nightly after crash reporter -> About Nightly Open.

Comment 3

[Ashish Namdev]

Attachment: Nightly-crash.log

Logs are attached for this crash .

Comment 4

[Ashish Namdev]

Hi 
what happened to this bug
it's still in New state ?

Comment 5

[Aaron Train [:aaronmt]]

Hi Ashish,

This bug is assigned but it is not a critically high-volume crash signature, albeit it is still decently sized so it's not a super high priority at the moment.

As for this signature — in the past 28 days, I see 327 crashes across all channels.

https://crash-stats.mozilla.com/report/list?product=FennecAndroid&range_unit=days&range_value=28&signature=java.lang.NullPointerException%3A+at+org.mozilla.gecko.toolbar.ToolbarDisplayLayout.updateFromTab%28ToolbarDisplayLayout.java%29

Comment 6

[Kevin Brosnan [:kbrosnan]]

Triage team wonders if this is mentorable.

Comment 7

[Lucas Rocha (:lucasr)]

(In reply to Kevin Brosnan [:kbrosnan] from comment #6)
> Triage team wonders if this is mentorable.

Kinda. The stacktrace is a bit weird. Might hard to debug. I'll try to have a look at it next week.

Comment 9

[Aaron Train [:aaronmt]]

See bug 1003229. What's special about visiting about:firefox that triggers this crash on some devices?

Comment 10

[Mark Finkle (:mfinkle) (use needinfo?)]

Bug 1003229 makes me a little worried.

Comment 11

[Lucas Rocha (:lucasr)]

I can't reproduce this in Fx29. Any known reliable STR? That would help figuring out what's going on here.

Comment 12

[Aaron Train [:aaronmt]]

I have yet been able to reproduce this. Ashish, which device are you using and which Android version?

Comment 13

[Ashish Namdev]

Hi Aaron

This seems not be reproducible in fx32 .

I am using samsung galaxy S2 device

Android 4.1.2

Comment 14

[Brian Nicholson (:bnicholson)]

100% reproducible using comment 2 with Don't Keep Activities enabled.

Comment 15

[Lucas Rocha (:lucasr)]

Attachment: Don't to update the toolbar state before it gets attachted (r=bnicholson)

Comment 16

[Lucas Rocha (:lucasr)]

Comment on attachment 8439205 [details] [diff] [review]
Don't to update the toolbar state before it gets attachted (r=bnicholson)

"Don't keep activities" causes updates to ToolbarDisplayLayout before it gets attached to a window. But ToolbarDisplayLayout can't be updated before it gets attached. Let's simply bail if that happens.

Comment 17

[Brian Nicholson (:bnicholson)]

Comment on attachment 8439205 [details] [diff] [review]
Don't to update the toolbar state before it gets attachted (r=bnicholson)

Review of attachment 8439205 [details] [diff] [review]:
-----------------------------------------------------------------

Commit message nits: s/Don't to update/Don't update/, s/attachted/attached/

Comment 18

[Lucas Rocha (:lucasr)]

https://hg.mozilla.org/integration/fx-team/rev/b136d95a45b2

Comment 19

[Ed Morley [:emorley]]

Backed out for:
https://tbpl.mozilla.org/php/getParsedLog.php?id=41666192&tree=Fx-Team
/builds/slave/fx-team-and-000000000000000000/build/mobile/android/base/toolbar/ToolbarDisplayLayout.java:265: cannot find symbol
symbol  : method isAttachedToWindow()
location: class org.mozilla.gecko.toolbar.ToolbarDisplayLayout
        if (!isAttachedToWindow()) {
             ^

remote:   https://hg.mozilla.org/integration/fx-team/rev/0cab2f679356

Comment 20

[Lucas Rocha (:lucasr)]

Replace isAttachedToWindow() with a local boolean member. Pushed: 
https://hg.mozilla.org/integration/fx-team/rev/595c7791bb16

Comment 21

[Brian Nicholson (:bnicholson)]

(In reply to Lucas Rocha (:lucasr) from comment #20)
> Replace isAttachedToWindow() with a local boolean member. Pushed: 
> https://hg.mozilla.org/integration/fx-team/rev/595c7791bb16

Why not just use getWindowToken() != null?

Comment 22

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/595c7791bb16

Comment 23

[Lucas Rocha (:lucasr)]

(In reply to Brian Nicholson (:bnicholson) from comment #21)
> (In reply to Lucas Rocha (:lucasr) from comment #20)
> > Replace isAttachedToWindow() with a local boolean member. Pushed: 
> > https://hg.mozilla.org/integration/fx-team/rev/595c7791bb16
> 
> Why not just use getWindowToken() != null?

Good point, forgot about this one. Not a big deal though. Do you feel strongly enough about it to want me to file a follow-up?

Comment 24

[Brian Nicholson (:bnicholson)]

(In reply to Lucas Rocha (:lucasr) from comment #23)
> Good point, forgot about this one. Not a big deal though. Do you feel
> strongly enough about it to want me to file a follow-up?

Nope, not a big deal like you said. Just curious if there was a reason.

Comment 25

[Brian Nicholson (:bnicholson)]

Although this would make a pretty good contributor bug!

Comment 26

[Lucas Rocha (:lucasr)]

Comment on attachment 8439205 [details] [diff] [review]
Don't to update the toolbar state before it gets attachted (r=bnicholson)

Approval Request Comment
[Feature/regressing bug #]: bug 944533
[User impact if declined]: Top crasher in Fx31 (#19) and Fx32 (#18).
[Describe test coverage new/current, TBPL]: No new instances of this crasher bug after this patch landed in Nightly (Fx33).
[Risks and why]: Low, simply guard against invalid update calls.
[String/UUID change made/needed]: n/a

Comment 27

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/e1b73deedcb4

Comment 28

[Teodora Vermesan (:TeoVermesan)]

Tested with:
Device: Samsung Galaxy Nexus
OS: Android 4.2.1

After performing the steps from comment 2 and comment 14, about firefox beta is opened, so verified fixed on:
Build: Firefox for Android 32 Beta 1

Comment 29

[Teodora Vermesan (:TeoVermesan)]

Tested with:
Device: Samsung Galaxy Nexus
OS: Android 4.2.1

After performing the steps from comment 2 and comment 14, about firefox aurora is opened, so verified fixed on:
Build: Firefox for Android 33.0a2 Aurora (2014-07-24)

Comment 30

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hi Margaret, Kevin: This bug is resolved & verified but the crash signature associated with it shows as top 3rd spot on Fennec Aurora 47. From the reports, I see the crash happening on 47.0a1 build 03-20. Should I re-open this or create a copy of this bug? Please let me know.

Comment 31

[Kevin Brosnan [:kbrosnan]]

We should file a new bug.