661978 - Input type file will cause a hang in fennec

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Attachment: 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

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

I was able to hang the browser by pressing back after following the steps in comment 0 when I pressed the system back key.

Comment 2

[Mike Hommey [:glandium]]

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.

Comment 3

[Mike Hommey [:glandium]]

Note the stock browser doesn't show an input field for input type="file"

Comment 4

[Mike Hommey [:glandium]]

That is, it only shows a "browse" button

Comment 5

[Doug Turner (:dougt)]

When this happens, I see GeckoApp::showFilePicker() be called, but it does not return.

Comment 6

[Doug Turner (:dougt)]

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

Comment 7

[Mike Hommey [:glandium]]

(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.

Comment 8

[Doug Turner (:dougt)]

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.

Comment 10

[Doug Turner (:dougt)]

Attachment: screenshot of blassey

this is another screenshot.  it shows blassey as I was explaining the hang to him over video.

Comment 11

[Doug Turner (:dougt)]

Attachment: patch v.1

this patch spins an event look to avoid deadlocking on the gecko thread.

Comment 12

[Brad Lassey [:blassey] (use needinfo?)]

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.

Comment 13

[Doug Turner (:dougt)]

THAT IS A GREAT IDEA!  Lets do that work in bug 680311.

Comment 14

[Doug Turner (:dougt)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/f9f4c9a737fb

Comment 15

[Marco Bonardo [:mak]]

http://hg.mozilla.org/mozilla-central/rev/f9f4c9a737fb

Comment 16

[Aaron Train [:aaronmt]]

VERIFIED FIXED!
Mozilla/5.0 (Android; Linux armv7l; rv:9.0a1) Gecko/20110819 Firefox/9.0a1 Fennec/9.0a1