This bug was filed from the Socorro interface and is report bp-79b4ead1-54e8-4011-911a-c960f2120219 . ============================================================= Java Stack Trace java.lang.NullPointerException at org.mozilla.gecko.BrowserToolbar.updateTabCountAndAnimate(BrowserToolbar.java:223) at org.mozilla.gecko.Tabs$1.run(Tabs.java:96) at android.os.Handler.handleCallback(Handler.java:605) at android.os.Handler.dispatchMessage(Handler.java:92) at android.os.Looper.loop(Looper.java:137) at org.mozilla.gecko.GeckoApp$34.run(GeckoApp.java:1824) at android.os.Handler.handleCallback(Handler.java:605) at android.os.Handler.dispatchMessage(Handler.java:92) at android.os.Looper.loop(Looper.java:137) at android.app.ActivityThread.main(ActivityThread.java:4507) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:511) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:790) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:557) at dalvik.system.NativeStart.main(Native Method) 2 reports; one dup of the other : on Build 2012021703 w/ Samsung GT-I9100
Seems like mTabCount is null (BrowserToolbar:223 in updateTabCountAndAnimate), which makes me think that updateTabCountAndAnimate is getting called before BrowserToolbar:init() Sriram - any idea how that could happen?
Assignee: nobody → sriram
This could be probably due to onNewIntent() being called in onResume(). I'll try moving the code to be after initialization.
Java crash; nom-ing for blocking fennec
blocking-fennec1.0: --- → ?
Is there a way to reproduce this bug?
There's only one crash in 13.0a1/20120217.
Increasing the Tab, without restoring, where mTabCount is null... not sure how mTabCount can be null other than perhaps starting from a different app? org.mozilla.gecko.BrowserToolbar.updateTabCountAndAnimate(BrowserToolbar.java:223) - http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/BrowserToolbar.java at org.mozilla.gecko.Tabs$1.run(Tabs.java:96) http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/Tabs.java https://github.com/android/platform_frameworks_base/blob/master/core/java/android/os/Handler.java https://github.com/android/platform_frameworks_base/blob/master/core/java/android/os/Looper.java going to try a few things to try to reproduce the issue.
Cannot seem to repro. Tried the following: 1) clearing data 2) launch from another app 1) clearing the data 2) install over 3) launch from another app 1) clean install (remove any existing, installing fresh) 2) launch from another app 1) clean install 2) launch from another app 3) hitting back button 4) opening another link
I have a weird feeling that it was because of onNewIntent(). That part has been removed now. So this might not happen at all. Please close the bug if this cannot be reproduced ;)
Not a top crash, not blocking. Still good to fix though.
blocking-fennec1.0: ? → -
(In reply to Sriram Ramasubramanian [:sriram] from comment #8) > I have a weird feeling that it was because of onNewIntent(). That part has > been removed now. So this might not happen at all. Please close the bug if > this cannot be reproduced ;) There's a recent crash in 13.0a1/20120304: bp-e393189b-0ffe-4e7b-ab82-ab42f2120305.
Created attachment 603452 [details] [diff] [review] Patch This might/might not fix the issue. :( Basically Tabs.addTab() is happening before BrowserToolbar is init(). Causing the problems. I don't know how this can happen. Gecko is start only after BrowserToolbar.init() though (inside initialize()). This patch moves the "assigning the views to private variables" part to "onFinishInflate()". Thereby the variables are not null even if addTab() gets called before init().
Attachment #603452 - Flags: review?(mark.finkle)
Comment on attachment 603452 [details] [diff] [review] Patch You move the variables, but not the code that uses the variables. If the variable (mTabsCount) was null before, why would it not be null now too?
Attachment #603452 - Flags: review?(mark.finkle) → review-
There has been quite a lot of changes and we dont have this crash for a long time now. Hence closing it.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.