Closed Bug 946479 Opened 6 years ago Closed 6 years ago

[B2G] [Everything.me] [Pinterest] The Gallery option in the Upload Your Photo menu does not launch the Gallery

Categories

(Core :: DOM: Device Interfaces, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla28
blocking-b2g koi+
Tracking Status
firefox26 --- wontfix
firefox27 --- wontfix
firefox28 --- fixed
b2g18 --- unaffected
b2g-v1.1hd --- unaffected
b2g-v1.2 --- fixed

People

(Reporter: ckreinbring, Assigned: baku)

References

Details

(Keywords: regression, Whiteboard: dogfood1.2)

Attachments

(3 files, 1 obsolete file)

Description:
In the Upload Your Photo menu while creating a Pinterest account, selecting the Gallery option fails to actually launch the Gallery app.

Repro Steps:
1) Update Buri to Build ID: 20131204004003
2) Launch the Pinterest app from Everything.me.
3) Tap Join Pinterest Today, then "your email address".
4) Tap the Upload Your Photo button and select Gallery from the menu that appears.
5) Observe the device's reaction.

Actual:
The screen goes black for a second or two before returning to Pinterest's Create Your Account page.

Expected:
The Gallery appears, allowing the user to select a picture to upload.

Environmental Variables
Device: Buri 1.2 commercial RIL
Build ID: 20131204004003
Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/758f3fb32dda
Gaia: 8d762f3376318fd6be390432db750ae4904c9ab6
Platform Version: 26.0
RIL Version: 01.02.00.019.102

Notes:
Does not repro on Leo 1.1 mozilla RIL
Repro frequency: 100%
See attached screenshot
No longer blocks: b2g-facebook
This sounds bad. Pinterest is a top site on the web (http://www.alexa.com/siteinfo/pinterest.com). In this case, the Gallery app is entirely failing to load when a file upload (i.e. input = file) option is selected.

Can someone get a dmesg log here when this bug reproduces? I think this is an OOM, but I'd like confirmation of that.
blocking-b2g: --- → koi?
Component: Preinstalled B2G Apps → Gaia::Gallery
Product: Tech Evangelism → Firefox OS
Milan,

Can you please review and reassign?

This seems to be a blocker though.
blocking-b2g: koi? → koi+
Flags: needinfo?(milan)
Why do we think this is graphics?  I see this in the log, is it related?

E/GeckoConsole(  109): [JavaScript Error: "[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIContentPermissionRequest.allow]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: jar:file:///system/b2g/omni.ja!/components/ContentPermissionPrompt.js :: handleExistingPermission :: line 86"  data: no]" {file: "jar:file:///system/b2g/omni.ja!/components/ContentPermissionPrompt.js" line: 86}]
Flags: needinfo?(milan)
(In reply to Milan Sreckovic [:milan] from comment #3)
> Why do we think this is graphics?  I see this in the log, is it related?
> 
> E/GeckoConsole(  109): [JavaScript Error: "[Exception... "Component returned
> failure code: 0x80004005 (NS_ERROR_FAILURE)
> [nsIContentPermissionRequest.allow]"  nsresult: "0x80004005
> (NS_ERROR_FAILURE)"  location: "JS frame ::
> jar:file:///system/b2g/omni.ja!/components/ContentPermissionPrompt.js ::
> handleExistingPermission :: line 86"  data: no]" {file:
> "jar:file:///system/b2g/omni.ja!/components/ContentPermissionPrompt.js"
> line: 86}]

Oh. Apparently the logcat here didn't include enough details here. This actually looks like a DOM regression.

Andrew - Can you find an assignee for this bug?
Component: Gaia::Gallery → DOM: Device Interfaces
Flags: needinfo?(overholt)
Product: Firefox OS → Core
Andrea said he would take a look here.
Assignee: nobody → amarchesini
Flags: needinfo?(overholt)
QA Contact: gbennett
Providing dmesg.
Keywords: qawanted
E/Sandbox (  728): install_syscall_filter() failed
E/GeckoConsole(  728): [JavaScript Warning: "Unknown property 'will-animate'.  Declaration dropped." {file: "app://gallery.gaiamobile.org/style/gallery.css" line: 146 column: 14 source: "  will-animate: scroll;"}]
E/GeckoConsole(  728): [JavaScript Warning: "Unknown property 'will-animate'.  Declaration dropped." {file: "app://gallery.gaiamobile.org/style/gallery.css" line: 306 column: 14 source: "  will-animate: scroll;"}]
I/Gecko:ProcessPriorityManager(  108): Add ChildID(11) into LRU pool
I/Gecko:ProcessPriorityManager(  108): [Gallery, child-id=11, pid=728] Changing priority from FOREGROUND:CPU_NORMAL to BACKGROUND:CPU_NORMAL.
I/Gonk    (  108): Setting nice for pid 728 to 18
I/Gonk    (  108): Changed nice for pid 728 from 1 to 18.
I/Gecko:ProcessPriorityManager(  108): Remove ChildID(11) from LRU pool
I/Gecko:ProcessPriorityManager(  108): [child-id=11, pid=-1] Destroying ParticularProcessPriorityManager.
I/Gecko   (  728): 
I/Gecko   (  728): ###!!! [Child][MessageChannel] Error: Channel closing: too late to send/recv, messages will be lost
I/Gecko   (  728): 
I/Gecko   (  108): [Parent 108] WARNING: waitpid failed pid:727 errno:10: file /home/baku/Sources/m/promise/src/ipc/chromium/src/base/process_util_posix.cc, line 254
I/Gecko   (  108): [Parent 108] WARNING: waitpid failed pid:727 errno:10: file /home/baku/Sources/m/promise/src/ipc/chromium/src/base/process_util_posix.cc, line 254
I/Gecko   (  108): [Parent 108] WARNING: Failed to deliver SIGKILL to 727!(3).: file /home/baku/Sources/m/promise/src/ipc/chromium/src/chrome/common/process_watcher_posix_sigchld.cc, line 118

The gallery app is killed. Now I check why...
This occurs for all Buri 1.2 builds since 06/21 (which is the first 1.2 build), and does not repro on the latest Leo 1.1

.:Last Working Build:.
Environmental Variables:
Device: Leo 1.1 mozRIL
BuildID: 20131205041342
Gaia: 6ff3a607f873320d00cb036fa76117f6fadd010f
Gecko: 05117f42088f
Version: 18.0
Firmware Version: V10d

.:First Broken Build:.
Environmental Variables:
Device: Buri 1.2 mozRIL
BuildID: 20130621031231
Gaia: e2f19420fa6a26c4287588701efaec09a750dba1
Gecko: 7ba8c86f1a56
Version: 24.0a1
Firmware Version: 20131115
the problem is about visibility. Gallery receives a visibilitychange event and it cancels the pick activity.
Do we know if something is changed with the visibility lately?

BTW: I'm able to reproduce this issue only with pinterest. a simple <input type="file"/> works fine.
Still debugging what pinterest does.
More information: pinterest.com creates 2 filePickers. It means that 2 activities are created and the latter disables the former. In the meantime I have a patch the disable to have more than 1 filePicker open at the same time. Uploading the patch...
Attached patch picker.patch (obsolete) — Splinter Review
This fixes the problem but still I don't know if the HTMLInputElement tries to open the filePicker twice because of some other bug.
Attachment #8343801 - Flags: review?(bzbarsky)
The reason why we have this issue is because pinterest does something like this:

<label id="label" for="for">bar</label>
<input type="file" name="foo" id="foo" />
<script>
$("#label").on('click', function() { $("#foo").click(); });

So the input foo receives 2 clicks - 1 from the label, 2nd from the script.

The patch looks green on try: https://tbpl.mozilla.org/?tree=Try&rev=320334c9b2b8
Comment on attachment 8343801 [details] [diff] [review]
picker.patch

>+  mPickerRunning = true;
>   return colorPicker->Open(callback);

What happens if Open() throws?  Will it still call the callback, or do you need to set mPickerRunning to false if it does?

   nsresult rv = filePicker->Init(win, title, mode);
+  mPickerRunning = true;

Again, what happens if filePicker->Open throws here?

r=me with those issues addressed.

I can't believe we had no reentrancy protection here.  :(
Attachment #8343801 - Flags: review?(bzbarsky) → review+
https://hg.mozilla.org/mozilla-central/rev/ccba2b6b092d
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Depends on: 958642
Depends on: 976724
You need to log in before you can comment on or make changes to this bug.