819 bytes, text/x-python
31.55 KB, text/plain
2.46 KB, patch
|Details | Diff | Splinter Review|
This bug was filed from the Socorro interface and is report bp-030ce5b2-6c44-4241-acca-d5d3d2140924. ============================================================= java.lang.IllegalStateException: empty actions queue at org.mozilla.gecko.GeckoEditable$ActionQueue.poll(GeckoEditable.java:305) at org.mozilla.gecko.GeckoEditable.notifyIME(GeckoEditable.java:748) at org.mozilla.gecko.GeckoAppShell.notifyIME(GeckoAppShell.java:510) at org.mozilla.gecko.mozglue.GeckoLoader.nativeRun(Native Method) at org.mozilla.gecko.mozglue.GeckoLoader.nativeRun(Native Method) at org.mozilla.gecko.GeckoAppShell.runGecko(GeckoAppShell.java:365) at org.mozilla.gecko.GeckoThread.run(GeckoThread.java:186) I hit this twice when inputing text into the search activity search field
(In reply to Aaron Train [:aaronmt] from comment #0) > I hit this twice when inputing text into the search activity search field Does GeckoEditable get used in the SearchActivity?
bug 1131985 doesn't always cause this crash. I added some more info to. HTH.
I've established that this bug is triggered by the use of startActivityForResult in the calling app. I have a python script that calls Firefox from within a QPython program. It uses startActivity(intent) and it works fine - calls the browser and returns to QPython when the back triangle is tapped. I amended it to use startActivityForResult(intent,0) as SparseRSS does. Firefox then exhibits this bug. (I don't know what 'result' the original program was or could be expecting.)
I intended to post that to bug 1131985 - sorry
I'm able to reproduce this crash constantly on Sony Xperia Z2 10" with Android 4.4.4: STR's: 1. Visit any site that contains a search field (e.g. google.com) 2. Tap into the search field -> VKB opens 3. Connect the device to the magnetic charger Result: Firefox crashes https://crash-stats.mozilla.com/report/index/07745d33-5c9c-4bba-9a14-cc1b72150406
That is kinda bazaar though str is cool. I think snorp was sent one of these tablets.
tracking-fennec: --- → ?
Jim, do you have a good idea of what's going on here?
I think I know what's going on.
Assignee: nobody → nchen
Status: NEW → ASSIGNED
Component: Search Activity → Keyboards and IME
I think the crash is happening because, when we get a new LayerView, we create a new GeckoEditable. If nsWindow is still processing IME events from the old GeckoEditable, it will reply to these events through the new GeckoEditable, which doesn't know about these old events. One simple fix is to only use one instance of GeckoEditable, and rebind it to the new LayerView when we have one. I removed the corresponding lines in GeckoApp because I think that code is obsolete now.
Attachment #8592270 - Flags: review?(esawin)
[Tracking Requested - why for this release]: Crash with fix, would be great to take if jchen is ok with uplift.
Jim, can we have an uplift request to aurora & beta? Thanks. Tracking as it is a crash.
Comment on attachment 8592270 [details] [diff] [review] Only create GeckoEditable once (v1) Approval Request Comment [Feature/regressing bug #]: N/A [User impact if declined]: Occasional crash in all current versions [Describe test coverage new/current, TreeHerder]: m-c [Risks and why]: Small risk due to changing startup path but nightly looks okay. [String/UUID change made/needed]: None
Verified as fixed on latest Nightly and Aurora Still needs to be verified on Beta 38.0b6
You need to log in before you can comment on or make changes to this bug.