There's one crash in 16.0a1/20120620: bp-f0dca13d-e00a-4618-858f-22afc2120620. java.lang.IndexOutOfBoundsException: Invalid index -1, size is 4 at java.util.ArrayList.throwIndexOutOfBoundsException(ArrayList.java:255) at java.util.ArrayList.add(ArrayList.java:147) at org.mozilla.gecko.TabsTray$TabsAdapter.addTab(TabsTray.java:224) at org.mozilla.gecko.TabsTray.onTabChanged(TabsTray.java:130) at org.mozilla.gecko.Tabs.notifyListeners(Tabs.java:355) at org.mozilla.gecko.Tabs.notifyListeners(Tabs.java:346) at org.mozilla.gecko.Tabs$1.run(Tabs.java:69) at android.os.Handler.handleCallback(Handler.java:587) at android.os.Handler.dispatchMessage(Handler.java:92) at android.os.Looper.loop(Looper.java:132) at android.app.ActivityThread.main(ActivityThread.java:4123) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:491) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:841) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:599) at dalvik.system.NativeStart.main(Native Method) More reports at: https://crash-stats.mozilla.com/query/query?product=FennecAndroid&query_search=signature&query_type=contains&query=java.util.ArrayList.throwIndexOutOfBoundsException&do_query=1
This looks like a regression caused by http://hg.mozilla.org/mozilla-central/rev/b7d5c0ed0d26.
Created attachment 635405 [details] [diff] [review] patch It looks like this can happen if a tab is added but then removed immediately, before the ADDED notification is processed. It might also be possible for the index to be too large, if some other tabs was closed right after this one was added, before the notification is processed. This patch checks for that scenario too.
Comment on attachment 635405 [details] [diff] [review] patch (In reply to Matt Brubeck (:mbrubeck) from comment #2) > It might also be possible for the index to be too large, if some other tabs > was closed right after this one was added, before the notification is > processed. This patch checks for that scenario too. If some other tab was closed but this one was added, I believe we'd still want to be adding this new tab to the TabsAdapter. We could just make sure to add the tab at the end in this case, but this makes me worry that it's also possible to be inserting tabs at the wrong index (e.g, you have multiple tabs, we add a tab somewhere in the middle, and the first tab gets deleted before the ADDED notification gets processed). It sounds to me like we need a more robust way to make sure we're adding the tab to the right place in TabsAdapter, but I'm not certain of a good approach. Perhaps add the index to the data passed along with the TabEvents.ADDED notification, but this still wouldn't help with races with CLOSED events. Maybe this is just something we can look into more when the adapter updates from bug 757198 finally land. r- for now to make sure we add the new tab if it does indeed exist. We can just adjust the index to add it at the end if the index is too large.
Created attachment 635453 [details] [diff] [review] patch v2 (In reply to Margaret Leibovic [:margaret] from comment #3) > r- for now to make sure we add the new tab if it does indeed exist. We can > just adjust the index to add it at the end if the index is too large. Fixed in this version.
Comment on attachment 635453 [details] [diff] [review] patch v2 https://hg.mozilla.org/integration/mozilla-inbound/rev/039721acef47 [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 765805 User impact if declined: crash when tabs open and close rapidly Testing completed (on m-c, etc.): Landed on inbound June 21 Risk to taking this patch (and alternatives if risky): Low-risk mobile patch that just adds a bounds-check before an array insertion. String or UUID changes made by this patch: None.
Comment on attachment 635453 [details] [diff] [review] patch v2 [Triage Comment] Low risk crash regression fix. Approved for Aurora 15.