Closed Bug 661978 Opened 9 years ago Closed 8 years ago

Input type file will cause a hang in fennec

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
Android
defect
Not set

Tracking

(firefox9 fixed, fennec+)

VERIFIED FIXED
Firefox 9
Tracking Status
firefox9 --- fixed
fennec + ---

People

(Reporter: nhirata, Assigned: dougt)

References

(Blocks 1 open bug)

Details

(Keywords: hang, mobile)

Attachments

(3 files)

Attached image screenshot
Mozilla/5.0 (Android; Linux armv71; rv7.0a1) Gecko/20110603 Firefox/7.0a1 Fennec/7.0a1
Device: Thunderbolt
OS: Android 2.2

1. go to http://people.mozilla.com/~nhirata/html_tp/NextAction_Bug614356.html
2. go to the section called "No form (should have next)"
3. click in the text field called "Last name:" and type something and hit the return key
4. click in the next field that is next to the browse button

Expected: A popup menu to choose a file appears and you can select an app
Actual: A popup menu appears but the app hangs
OS: Mac OS X → Android
Hardware: x86 → ARM
I was able to hang the browser by pressing back after following the steps in comment 0 when I pressed the system back key.
tracking-fennec: --- → ?
Keywords: hang, mobile
I see something similar on an ASUS transformer (honeycomb 3.1) when touching an input type="file" on, e.g. the bugzilla page to file a new bug with an attachment, though the "browse" button next to it does work properly.
Note the stock browser doesn't show an input field for input type="file"
That is, it only shows a "browse" button
Assignee: nobody → doug.turner
tracking-fennec: ? → +
When this happens, I see GeckoApp::showFilePicker() be called, but it does not return.
mike -- when this happens to you, do you see a large black area at the bottom of the screen where, perhaps, the software keyboard could be?n
(In reply to comment #6)
> mike -- when this happens to you, do you see a large black area at the
> bottom of the screen where, perhaps, the software keyboard could be?n

No. neither with or without the hardware keyboard attached.
startActivityForResult, for some reason, doesn't always call onActivityResult.  If onActivityResult isn't called, our implementation will wait on a monitor and never will wake up.


Where we call startActivityForResult:

http://mxr.mozilla.org/mozilla-central/source/embedding/android/GeckoApp.java#664

Where we wait:

http://mxr.mozilla.org/mozilla-central/source/embedding/android/GeckoApp.java#669

Where we notify:

http://mxr.mozilla.org/mozilla-central/source/embedding/android/GeckoApp.java#728


Looking at my logging, it clearly suggests that onActivityResult isn't called.
Duplicate of this bug: 677562
Attached image screenshot of blassey
this is another screenshot.  it shows blassey as I was explaining the hang to him over video.
Attached patch patch v.1Splinter Review
this patch spins an event look to avoid deadlocking on the gecko thread.
Attachment #554189 - Flags: review?(blassey.bugs)
Comment on attachment 554189 [details] [diff] [review]
patch v.1

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

GOOD JOB DOUG!!

We should probably do this for all of our sync queues that are called on the gecko thread. Please file a follow up bug for that.
Attachment #554189 - Flags: review?(blassey.bugs) → review+
Blocks: 680311
THAT IS A GREAT IDEA!  Lets do that work in bug 680311.
http://hg.mozilla.org/mozilla-central/rev/f9f4c9a737fb
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 9
VERIFIED FIXED!
Mozilla/5.0 (Android; Linux armv7l; rv:9.0a1) Gecko/20110819 Firefox/9.0a1 Fennec/9.0a1
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.