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

RESOLVED FIXED in Firefox 30

Status

()

RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: croesch, Assigned: baku)

Tracking

({regression})

unspecified
mozilla30
ARM
Gonk (Firefox OS)
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:1.3+, 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)

Details

(Whiteboard: dogfood1.3)

Attachments

(3 attachments)

(Reporter)

Description

5 years ago
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
(Reporter)

Comment 1

5 years ago
Created attachment 8358546 [details]
log.txt
(Reporter)

Comment 2

5 years ago
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
(Reporter)

Comment 3

5 years ago
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

Updated

5 years ago
QA Contact: mvaughan

Comment 5

5 years ago
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
Keywords: regressionwindow-wanted
(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
(Assignee)

Comment 7

5 years ago
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]
(Assignee)

Comment 14

5 years ago
> 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

Comment 16

5 years ago
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
(Assignee)

Comment 17

5 years ago
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.
(Assignee)

Comment 18

5 years ago
I tried again today with the latest 1.3. I cannot reproduce this issue.
Keywords: qawanted

Comment 19

5 years ago
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)
(Assignee)

Comment 22

5 years ago
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.

Comment 23

5 years ago
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.

Updated

5 years ago
Flags: needinfo?(jhammink)
(Assignee)

Comment 24

5 years ago
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.
(Assignee)

Comment 28

5 years ago
(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.
(Assignee)

Comment 30

5 years ago
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+
https://hg.mozilla.org/mozilla-central/rev/2e3eaecb7992
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/385a1417c291
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
Depends on: 976454
status-b2g-v1.3T: --- → fixed
You need to log in before you can comment on or make changes to this bug.