948232 - [B2G][Gallery] Image does not upload the first time to Twitter app when sharing through Gallery app

Status: RESOLVED WONTFIX

(Tech Evangelism Graveyard :: Preinstalled B2G Apps, defect, P2)

Description

[Nikolai Khristoforov]

Attachment: Logcat

When the user tries to share an image in the Gallery app through Twitter, the image upload to Twitter is not successful the first time and they get routed back to the full-screen view of the image instead of the Create Tweet page. If they attempt to share it again, then they will be able to upload the image 80% of the time.

Repro Steps:
1) Updated Buri v1.3 to BuildID: 20131209053402
2) Install the Twitter app through the Marketplace.
3) Sign in to Twitter through the app.
4) Make sure the Gallery has at least one image.
5) Open the Gallery and select a image.
6) Select the Share button and the Twitter option.
7) Verify that the user is returned back to full-screen view of the image.

Actual:
The image does not get uploaded to Twitter and the user is returned to the image in the Gallery app.

Expected:
The image would get uploaded to Twitter and the user would be routed to the Create Tweet page.

Environmental Variables:
Device: Buri v1.3 Moz RIL
BuildID: 20131209053402
Gaia: 1d45d1dc3201059d5c8f2efdeb92c04576d8e161
Gecko: 9f12a9fab080
Version: 28.0a1
Firmware Version: V1.2_20131115

Repro frequency: 100% the first time, 20% the second time
Link to failed test case: https://moztrap.mozilla.org/manage/case/2317/
See attached: Logcat and Youtube video (http://youtu.be/Nnnb_wZ2Mt4)

Comment 1

[Nikolai Khristoforov]

The bug does not reproduce on the latest 1.2 and 1.1 builds. The user is able to upload the image to Twitter.

Device: Buri v1.2 Moz RIL
BuildID: 20131209004003
Gaia: f615ae7acb6731d191b3094e10e314bc28359bbb
Gecko: f684b8f159a3
Version: 26.0

Comment 2

[Nikolai Khristoforov]

The regression window for this bug is 11-27 to 11-28.

Last Working Build:
Device: Buri v1.3 Moz RIL
BuildID: 20131127040203
Gaia: d4b9a3d271f0451b4d903a03c2b931b8cc092041
Gecko: 6ecf0c4dfcbe
Version: 28.0a1

First Broken Build:
Device: Buri v1.3 Moz RIL
BuildID: 20131128040201
Gaia: 0d57ec2801ae125ec855a19cf956ab118660d694
Gecko: a5e7f611546f
Version: 28.0a1

Comment 3

[John Hu [:johnhu][:johu][:醬糊小弟]]

It works with master build: 2013-12-11-04-02-03. Someone may fix this bug already. And we still need to find which patch fixes this.

Comment 4

[Marcia Knous [:marcia]]

need info to retest this per the Media triage on 12-18.

Comment 5

[Marcia Knous [:marcia]]

Confirming with testing that this bug is still present on the latest 1.3 build on Buri, using:

Gaia   a99249a7fdf9f20850d98a9a222385676d472362
SourceStamp 809aabadac6d
BuildID 20131219004002
Version 28.0a2

The first time I try to upload the image it did not work, but the second time it did. As John notes in Comment 3 this does work on the latest Mozilla Central. Looks as if the fix is needed on 1.3.

Comment 6

[Hema Koka [:hema]]

John, please take a look at this bug. It probably is a matter of uplifting the patch from master that already fixes this problem.

Thanks
Hema

Comment 7

[Punam Dahiya [:pdahiya]]

Hi John
I spent some time yesterday looking into this bug and here are my findings: 

This issue is replicable on mozilla-central on below builds
BuildId: 20131213040203
BuildId: 201407040206 (latest m-c, gaia master)

Error in logs first time user click twitter option to share an image. This error is not seen when user tries second time to share image on twitter

01-07 19:22:02.929 E/QCALOG  (  206): [MessageQ] ProcessNewMessage: [XTWiFi-PE] unknown deliver target [OS-Agent]
01-07 19:22:06.029 I/GeckoDump(  158): XXX FIXME : Got a mozContentEvent: activity-choice
01-07 19:22:06.069 I/Gecko:ProcessPriorityManager(  158): [(Preallocated), child-id=21, pid=1659] Changing priority from BACKGROUND:CPU_NORMAL to FOREGROUND:CPU_NORMAL.
01-07 19:22:06.069 I/Gonk    (  158): Setting nice for pid 1659 to 1
01-07 19:22:06.069 I/Gonk    (  158): Changed nice for pid 1659 from 18 to 1.
01-07 19:22:06.069 E/Sandbox ( 1659): install_syscall_filter() failed
01-07 19:22:06.079 I/Gecko:ProcessPriorityManager(  158): [Twitter, child-id=21, pid=1659] Got wake lock changed event. Now mHoldsCPUWakeLock=1, mHoldsHighPriorityWakeLock=0
01-07 19:22:06.359 I/Gecko:ProcessPriorityManager(  158): [Gallery, child-id=20, pid=1566] Got wake lock changed event. Now mHoldsCPUWakeLock=0, mHoldsHighPriorityWakeLock=0
01-07 19:22:06.389 E/GeckoConsole(  158): [JavaScript Error: "An error occurred during a connection to mobile.twitter.com:80.
01-07 19:22:06.389 E/GeckoConsole(  158): 
01-07 19:22:06.389 E/GeckoConsole(  158): SSL received a record that exceeded the maximum permissible length.
01-07 19:22:06.389 E/GeckoConsole(  158): 
01-07 19:22:06.389 E/GeckoConsole(  158): (Error code: ssl_error_rx_record_too_long)
01-07 19:22:06.389 E/GeckoConsole(  158): "]
01-07 19:22:06.459 E/GeckoConsole(  158): [JavaScript Error: "An error occurred during a connection to mobile.twitter.com:80.
01-07 19:22:06.459 E/GeckoConsole(  158): 
01-07 19:22:06.459 E/GeckoConsole(  158): SSL received a record that exceeded the maximum permissible length.
01-07 19:22:06.459 E/GeckoConsole(  158): 
01-07 19:22:06.459 E/GeckoConsole(  158): (Error code: ssl_error_rx_record_too_long)
01-07 19:22:06.459 E/GeckoConsole(  158): "]
01-07 19:22:06.609 I/Gecko   ( 1566): Attempting load of libEGL.so
01-07 19:22:06.669 I/Adreno200-EGL( 1566): <qeglDrvAPI_eglInitialize:295>: EGL 1.4 QUALCOMM build:  (Merge)
01-07 19:22:06.669 I/Adreno200-EGL( 1566): Build Date: 09/02/13 Mon
01-07 19:22:06.669 I/Adreno200-EGL( 1566): Local Branch: b2g_autogen_ephemeral_branch
01-07 19:22:06.669 I/Adreno200-EGL( 1566): Remote Branch: 
01-07 19:22:06.669 I/Adreno200-EGL( 1566): Local Patches: 
01-07 19:22:06.669 I/Adreno200-EGL( 1566): Reconstruct Branch: 
01-07 19:22:06.869 I/Gecko   ( 1566): SharedSurface_Gralloc::Create -------
01-07 19:22:06.869 I/Gecko   ( 1566): SharedSurface_Gralloc::Create: success -- surface 0x43fffec0, GraphicBuffer 0x44061f00.
01-07 19:22:06.949 E/Profiler(  158): BPUnw: [1 total] thread_unregister_for_profiling(me=0x677c10)  (NOT REGISTERED)

Comment 8

[John Hu [:johnhu][:johu][:醬糊小弟]]

Hi Punam,

Thanks for that. I had noticed the same error but not sure if they are related to this bug. There are two significant errors here:
1. XXX FIXME : Got a mozContentEvent: activity-choice
     I can get the same error no matter the first or second time to share the image. And when this error happens, I need to tap the twitter option again to activate it.

2. [JavaScript Error: "An error occurred during a connection to mobile.twitter.com:80.
     I feel this one may be the root cause of this bug because it uses https protocol whose port is 443 instead of 80. But I still need to try to clarify if it does cause this bug.

With some debugging code inside system app, I also found another strange thing here:
i. The activity is done immediate when first time to share, which can be captured at [1]. That's the reason we get the gallery app when we do the first time sharing.
ii. The onsuccess event of MozActivity is fired no matter the twitter page is opened or not.

The url of twitter page to handle share activity is https://mobile.twitter.com/compose/tweet

[1] https://github.com/mozilla-b2g/gaia/blob/3e3ef593bec55d573e0f906a75986c2516229d11/apps/system/js/app_window.js#L526

Comment 9

[John Hu [:johnhu][:johu][:醬糊小弟]]

Attachment: share image from ui test and gallery app

To have more information about the symptom of this bug, I had tested with both uitest app and gallery app.

In this short video, it shows two symptoms here:

1. The first sharing which is shared from uitest app works. But the caller window is brought to foreground based on the finding i in comment 8. We may find that at 00:16 of this video.

2. The second sharing which is shared from gallery app doesn't work. The twitter window is opened correctly, no caller window at foreground. But the sharing activity doesn't handled by twitter app. We may find that at 00:30 of this video.

Comment 10

[John Hu [:johnhu][:johu][:醬糊小弟]]

More information about comment 9:

If we swap the app used at first and second sharing, the symptoms are still the same. The first sharing worked and the second sharing failed. But the first sharing is covered by the caller window and not in the second sharing.

Comment 11

[John Hu [:johnhu][:johu][:醬糊小弟]]

When we open the twitter app first time, we still get the ssl error but the app works correctly:

E/GeckoConsole(  112): [JavaScript Error: "An error occurred during a connection to mobile.twitter.com:80.
E/GeckoConsole(  112): 
E/GeckoConsole(  112): SSL received a record that exceeded the maximum permissible length.
E/GeckoConsole(  112): 
E/GeckoConsole(  112): (Error code: ssl_error_rx_record_too_long)
E/GeckoConsole(  112): "]

I think this error may not be related to this bug. Because twitter app navigates to https://mobile.twitter.com/compose/tweet at the first sharing. The twitter app is loaded when we do the second sharing. That's the reason we don't get the same error at the second sharing.

When we kill the twitter app after the first sharing and do the second sharing, this error still can be found. That's another proof.

Comment 12

[John Hu [:johnhu][:johu][:醬糊小弟]]

Attachment: Share to Facebook

I had tested the same procedure with Facebook app which is also a hosted app and accepts image share activity.

In this video, we can find with the same codebase Facebook app works correctly. When we do the share multiple times, it attaches multiple files to the same post. But that's not correct with twitter app.

Comment 13

[John Hu [:johnhu][:johu][:醬糊小弟]]

Ok, I think I got what's going on.

According to regression window, I found the patch[1] creates this bug. But the window.js had been rewrote as app_window.js in the current build. The behavior of app_windows.js and the patch[1] are correct. They handle the `mozbrowseractivitydone` event and show the caller window when the share activity is processed, according to the offline discussion with alive.

In the video of comment 12, the Facebook web handles activity and calls activity.postResult() correctly. So, we can have the expected behavior to share image to Facebook.

But in video of comment 9 and url of this bug, the Twitter web seems to call activity.postResult/postError() while receiving the activity. So, system app brings the caller window back as expected. That's the reason why we cannot share the image to Twitter at first time.

In the findings of comment 9 and comment 10 comparing to video of comment 12, we may say the Twitter web doesn't use mozSetMessageHandler and mozHasPendingMessage to handle two or more activity requests. Their javascript codes are minified so that I can check for that. In contrast, Facebook web appends the image blob of second share activity to the post which is created by the first share activity. That's the correct behavior. That's also the reason we can have Twitter web window opened at the second sharing and the symptom 2 of comment 9. Because they just do nothing when the page is already in compose/tweet page.

Jason,

I don't know who should I need info about this kind of issue. Would you mind to help me to transfer to the correct person? Thanks.

[1] https://github.com/mozilla-b2g/gaia/commit/b9023366dfa7c15f943917985e553245dc01b065

Comment 14

[Jason Smith [:jsmith]]

So if I understand this bug correctly, we're now doing more of the correct behavior with activity handling in the window manager. However, in following correct behavior more closely, we've revealed a bug in Twitter's implementation. Therefore, this is a TE bug with Twitter.

I'll send this bug over to Elisa to outreach to Twitter to fix this bug then.

Comment 15

[Elisa Helton]

Hello Jeremy, please review this bug and let us know when you think it can be fixed. Thank you.

Comment 16

[Jeremy Forrester]

Crossposted as MTWO-139, I'll let you know when I have more information

Comment 17

[Nicole Fong]

Hi Jeremy, are there any updates regarding this bug?

Comment 18

[joseenrique.alvarezfernandez]

Seems to be solved on OPENC v1.3 build 20140325120432. Can anyone confirm?

Comment 19

[Nicole Fong]

Still able to reproduce on Buri 1.3

Comment 20

[joseenrique.alvarezfernandez]

ok. reproduced. The first time you try to share de photo from the gallery, it gets back to the gallery app. If you try it a second time, then you finally reach to Twitter app

Comment 21

[Sylvestre Ledru [:Sylvestre]]

Mass closing on Tech Evangelism::Preinstalled B2G App as Firefox OS is no longer a thing.

Comment 22

[Sylvestre Ledru [:Sylvestre]]

Mass closing on Tech Evangelism::Preinstalled B2G App as Firefox OS is no longer a thing.

Comment 23

[Sylvestre Ledru [:Sylvestre]]

Mass closing on Tech Evangelism::Preinstalled B2G App as Firefox OS is no longer a thing.