Created attachment 8358545 [details] Unresponsive upload button 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
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
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
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.
Assignee: nobody → amarchesini
blocking-b2g: 1.3? → 1.3+
Is this under system front end team's radar?
(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.
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.
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
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.
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
Can we get ETA to fix this bug? Thank you.
John Please take a look for reproducibility
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.
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
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.
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.
Created attachment 8371560 [details] [diff] [review] activity.patch Here a patch for this bug.
Attachment #8371560 - Flags: review?(fabrice)
Attachment #8371560 - Flags: review?(fabrice) → review+
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
status-b2g-v1.1hd: --- → unaffected
status-b2g-v1.3: affected → fixed
status-b2g-v1.4: --- → fixed
status-firefox28: --- → wontfix
status-firefox29: --- → wontfix
status-firefox30: --- → fixed
You need to log in before you can comment on or make changes to this bug.