Closed Bug 958642 Opened 10 years ago Closed 10 years ago

[B2G][Browser] Browse button for uploading files on a craigslist posting becoming unresponsive

Categories

(Core :: DOM: Core & HTML, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla30
blocking-b2g 1.3+
Tracking Status
firefox28 --- wontfix
firefox29 --- wontfix
firefox30 --- fixed
b2g18 --- unaffected
b2g-v1.1hd --- unaffected
b2g-v1.2 --- unaffected
b2g-v1.3 --- fixed
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed

People

(Reporter: croesch, Assigned: baku)

References

Details

(Keywords: regression, Whiteboard: dogfood1.3)

Attachments

(3 files)

When a user tries to upload a video to a craigslist post and the device is plugged in via USB with USB Storage enabled, the user will get a message saying that videos can't be viewed when plugged in. There is no back button so the user must tap the HOME button then go back into Craigslist, the Browse button is now unresponsive.

Repro Steps:
1) Update Buri to Build ID: 20140106004001
2) Plug the device in via USB to a PC.
3) Enable USB Storage in Settings.
4) Go to Craigslist.org on the phone or download and launch the Craigslist app.
5) Post to classifieds and choose to post an item for sale or wanted.
6) Fill out all necessary information until you get to upload images page.
7) Tap on the Upload button to bring up the upload options.
8) Tap the Videos option.
9) Notice that the user gets a message that videos can't be viewed when device is plugged in.
10) There is no back button so the user must tap home and reload craigslist
11) If the user tries to tap on the Upload button again, the button will be unresponsive now. 

Actual:
The upload button for posting on Craigslist breaks if the phone is plugged in and being used as USB Storage.

Expected:
The upload button for craigslist should not become unresponsive if the user tries to upload a video.

Environmental Variables
Device: Buri v 1.3.0 Moz RIL
Build ID: 20140106004001
Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/a43cb4b322d3
Gaia: 35a60b82f8cf2d759939a350e2dadbb9d8b2f5dc
Platform Version: 28.0a2

Notes:
Repro frequency:  100%

This issue also occurs if there are no videos on the device when the user tries to access the videos option and the user gets the message to Add Videos to get Started.

See Attached: Video
Attached file log.txt
This bug does NOT happen in 1.1 or 1.2

1.1 Environmental Variables
Device: Buri v 1.1.0 COM RIL 
Build ID: 20140102041202
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/bdac595a4e46
Gaia: 6ff3a607f873320d00cb036fa76117f6fadd010f
Platform Version: 18.1
RIL Version: 01.01.00.019.281


This issue also occurs on the latest Buri v 1.2.0 Mozilla RIL

Environmental Variables
Device: Buri v 1.2.0 Mozilla RIL
Build ID: 20140106004001
Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/d552c08a72d0
Gaia: 8441587c3b352e052fee07665c21fd192540f19f
Platform Version: 26.0
The reason this is a problem is:
1. If a user accidentally chooses video option, they are unable to recover and go back choose images.
2. It may highlight a need for a back button on messages for unable to view videos when device is plugged in and no videos present on this device message windows.
This looks like a regression with activity management with the pick activity via the input=file element.
blocking-b2g: --- → 1.3?
Component: Gaia::Browser → Gaia::System::Window Mgmt
QA Contact: mvaughan
This issue started reproducing on the 12/08/13 1.3 build.

- Works -
Environmental Variables:
Device: Buri v1.3 MOZ RIL
BuildID: 20131207040203
Gaia: 1abda08e450cb66a61a31bdcfd3352e2df9d9ace
Gecko: 42b2a2adda8f
Version: 28.0a1
Firmware Version: V1.2_US_20131115

- Broken -
Environmental Variables:
Device: Buri v1.3 MOZ RIL
BuildID: 20131208040203
Gaia: 1abda08e450cb66a61a31bdcfd3352e2df9d9ace
Gecko: edac8cba9f78
Version: 28.0a1
Firmware Version: V1.2_US_20131115
(In reply to croesch from comment #3)
> The reason this is a problem is:
> 1. If a user accidentally chooses video option, they are unable to recover
> and go back choose images.
> 2. It may highlight a need for a back button on messages for unable to view
> videos when device is plugged in and no videos present on this device
> message windows.

The behavior above is not regression. We have never been able to go back in the picker screen IMHO.

However, having a unresponsive browse button is indeed a regression and I suspect something on the platform broke this (there is no way Gaia could do stop browse button from responsive).

Changing compartment.
Component: Gaia::System::Window Mgmt → General
Component: General → DOM
Product: Firefox OS → Core
I suspect what the issue is:
HTMLInputElement can have just 1 file picker opened. On b2g, the file picker uses MozActivity to open apps. But if the selected app doesn't abort the activity, the filePicker doesn't abort its task and HTMLInputElement would not open a new one when the user clicks again on it.
(In reply to Andrea Marchesini (:baku) from comment #7)
> I suspect what the issue is:
> HTMLInputElement can have just 1 file picker opened. On b2g, the file picker
> uses MozActivity to open apps. But if the selected app doesn't abort the
> activity, the filePicker doesn't abort its task and HTMLInputElement would
> not open a new one when the user clicks again on it.

Okay - but do we know what regressed here specifically? Apparently this worked before, but it doesn't now.
bug 946479 broke this.
Blocks: 946479
Assignee: nobody → amarchesini
blocking-b2g: 1.3? → 1.3+
Is this under system front end team's radar?
Flags: needinfo?(cserran)
(In reply to Kevin Hu [:khu] from comment #11)
> Is this under system front end team's radar?

The DOM team is looking into this.
(In reply to Jason Smith [:jsmith] from comment #12)
> (In reply to Kevin Hu [:khu] from comment #11)
> > Is this under system front end team's radar?
> 
> The DOM team is looking into this.

Thank you, Jason.
Flags: needinfo?(cserran)
Whiteboard: dogfood1.3 → dogfood1.3 [systemsfe]
> The behavior above is not regression. We have never been able to go back in
> the picker screen IMHO.

I cannot reproduce this issue. I use inari, with the last gaia and the last m-c version.
I see the cancel button, and doing all the steps 1 by 1, still I can re-open the file picker.

Could it be that is an old issue?
QA Wanted to check this on the latest 1.3 build.
Keywords: qawanted
This issue reproduces for me on the 01/21/14 1.3 build.

Environmental Variables:
Device: Buri v1.3 MOZ RIL
BuildID: 20140121004137
Gaia: 47049555282a9a01fb60d1e1421b57e2810c96f5
Gecko: 6f7dfe36ab6c
Version: 28.0a2
Firmware Version: V1.2-device.cfg
Keywords: qawanted
Whiteboard: dogfood1.3 [systemsfe] → dogfood1.3
I don't know if this helps, but I was doing the tests with 1.4 and there I cannot reproduce the issue.
I'm going again with 1.3.
I tried again today with the latest 1.3. I cannot reproduce this issue.
Keywords: qawanted
This issue does still reproduce for me on the 02/03/14 1.3 and Master (1.4) builds. Because of the Rocket Bar on 1.4, the STR is a little different. When getting the message that you cannot view video files while the phone is plugged in with the USB connection enabled, hit the Home button (not the Cancel button) and then navigate back to Craigslist through the task manager area. If you hit "Cancel" when getting the message, then the issue won't reproduce.

- Buri 1.3 Build -
Device: Buri v1.3 MOZ RIL
BuildID: 20140203004001
Gaia: f9a37c77efb4621a1f57e4695b497d18601fe134
Gecko: 3d9d920ca43b
Version: 28.0a2
Firmware Version: V1.2-device.cfg
Keywords: qawanted
Can we get ETA to fix this bug? Thank you.
John

Please take a look for reproducibility
Flags: needinfo?(jhammink)
I can randomly reproduce this issue. I suspect it's a gaia bug:
E/GeckoConsole(  112): Content JS WARN at app://system.gaiamobile.org/js/activity_window.js:235 in onClose: unknown window type of activity caller.

On B2G the FilePicker is implemented on top of pick activities. If the activity is not dismissed when the home button is touched by the user, the filePicker doesn't receive an answer and the <input type="file"> becomes unresponsive.

I'm investigating why system app is failing.
Yep, John Schoenick and I reproduced this issue, as written above, on the following build:

Gaia      f9a37c77efb4621a1f57e4695b497d18601fe134
Gecko     http://hg.mozilla.org/releases/mozilla-aurora/rev/3d9d920ca43b
BuildID   20140203004001
Version   28.0a2
ro.build.version.incremental=324
ro.build.date=Thu Dec 19 14:04:55 CST 2013

John's taking my phone over to Baku now.
Flags: needinfo?(jhammink)
Alive, I think I need your help to debug this issue. I'm not familiar with this code.
What I see is that <gecko>/b2g/chrome/content/shell.js creates the MozActivity but it doesn't receive any success/error callback.
Putting needinfo on Alive per the above comment
Flags: needinfo?(alive)
This won't be gaia issue I think.
I could reproduce on v1.3 but what I see is I remove the activity iframe correctly.
Once the frame is destructed, gecko should do postError for the frame.

Please investigate from gecko again.
Flags: needinfo?(alive)
See http://mxr.mozilla.org/mozilla-central/source/dom/activities/src/ActivityWrapper.js#59
When the iframe is destroyed it's supposed to have inner-window-destroyed notification and ActivityWrapper would do postError then you are supposed to know it's canceled here.
(In reply to Alive Kuo [:alive][NEEDINFO!][:艾莉芙][Paris 2/3-2/7] from comment #27)
> See
> http://mxr.mozilla.org/mozilla-central/source/dom/activities/src/
> ActivityWrapper.js#59
> When the iframe is destroyed it's supposed to have inner-window-destroyed
> notification and ActivityWrapper would do postError then you are supposed to
> know it's canceled here.

Correct. But it doesn'.t That code is not called at all. What I suspect is because the app is killed so that notification is not received by the app it self (ActivityWrapper runs in the child).

Debugging it a bit it turned out that we are leaking in many places:

. SystemMessageInternal.js doesn't delete the _listeners item in the array
. ActivitiesService.jsm doesn't delete the Activities.callers item as well
. The activityProxy is still alive
. The FilePicker is still alive
. nsIFilePicker obj in still alive in the HTMLInputElement
As talked offline, unless the activity iframe isn't removed so I think this is not a gaia bug anyway.
Attached patch activity.patchSplinter Review
Here a patch for this bug.
Attachment #8371560 - Flags: review?(fabrice)
Attachment #8371560 - Flags: review?(fabrice) → review+
https://hg.mozilla.org/mozilla-central/rev/2e3eaecb7992
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Depends on: 976454
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: