1110062 - [Flame][Gallery]Device auto come back to gallery while we select images to share via twitter.

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Paladin]

Attachment: auto_come_back.3gp

[1.Description]:
[Flame][v2.1&2.2][Gallery]Device automatically comes back to gallery while we select to share images via twitter.
Attachment: logcat_flame_1240.txt and auto_come_back.3gp
Occurrence time: 12:40

[2.Testing Steps]: 
1. Open Gallery App 
2. Tap on any photo. 
3. Tap "share picture"
4. Select "Twitter". 


[3.Expected Result]: 
4. We can enter into twitter page of editing message.

[4.Actual Result]: 
4. Twitter app is launched and device automatically comes back to Gallery.

[5.Reproduction build]: 
Gaia-Rev        c226db212db4d824c09617cd6dc407b2d4258d9b
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/cf8bebfa4703
Build-ID        20141210001201
Version         34.0

Flame 2.2 build:
Gaia-Rev        e17c5656dbf517d48fb61ac9bc92119e023fd717
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/be1f49e80d2d
Build-ID        20141210040201
Version         37.0a1

[6.Reproduction Frequency]: 
Always Recurrence,5/5
TCID: 2317

Comment 1

[Paladin]

Attachment: logcat_flame_1240.txt

Comment 2

[Lance（leave from Mozilla）]

The bug still exist in latest Flame 2.1, 2.2, 3.0 and 2.1s. Ater you share a image to Twitter, device will back to image view.

Steps:
Prerequisite: You have install Twitter and log in an account.
1. Open Gallery App 
2. Tap on any photo. 
3. Tap "share picture"
4. Select "Twitter". 

Expected Result: 
4. We can enter into twitter page of editing message.

Actual Result: 
4. Twitter app is launched and device automatically comes back to Gallery.

Fail rate: 2/5
See attachment:847.mp4 and logcat_847.txt

Flame 2.1 version:
Build ID               20150308001818
Gaia Revision          ea97a87048a4c1e2a479bbea1d75e0a182b2c4c9
Gaia Date              2015-03-05 16:30:05
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/0443f2e951dc
Gecko Version          34.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150308.045836
Firmware Date          Sun Mar  8 04:58:47 EDT 2015
Bootloader             L1TC000118D0

Flame 2.2 version:
Build ID               20150308002503
Gaia Revision          166491b92278dc9e648f8d49ab02d9ca00d74421
Gaia Date              2015-03-06 18:26:27
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/a48af0b5a6e4
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150308.052515
Firmware Date          Sun Mar  8 05:25:25 EDT 2015
Bootloader             L1TC000118D0

Flame 3.0 version:
Build ID               20150308160204
Gaia Revision          fea83511df9ccba64259346bc02ebf2c417a12c2
Gaia Date              2015-03-08 06:36:28
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/eab4a81e4457
Gecko Version          39.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150308.192120
Firmware Date          Sun Mar  8 19:21:31 EDT 2015
Bootloader             L1TC000118D0

2.1s(512m) version:
Build ID               20150308161201
Gaia Revision          ea97a87048a4c1e2a479bbea1d75e0a182b2c4c9
Gaia Date              2015-03-05 16:30:05
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/c1ba3b3ec5aa
Gecko Version          34.0
Device Name            scx15_sp7715ea
Firmware(Release)      4.4.2
Firmware(Incremental)  122
Firmware Date          Thu Feb  5 12:42:58 CST 2015

Comment 3

[Lance（leave from Mozilla）]

Attachment: logcat_847.txt

Comment 4

[Lance（leave from Mozilla）]

Attachment: 847.MP4

Comment 5

[William Hsu [:whsu]]

[Blocking Requested - why for this release]:

[Blocking Requested - why for this release]:

This is quite basic functionality.
Could we fix it?

Comment 6

[Mike Lien[:mlien]]

Hi Lance, could I have your help, what is the memory setting you use to reproduce issue.
It looks like the memory pressure is high and I cannot reproduce it with v2.1 both 1G and 319MB.
Please also attach the kernel log "adb shell dmesg" for investigation, thanks.

Gaia-Rev        a227b67d9ae647cc949ec1ef48ced00c80240025
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/a61c9c3dfba7
Build-ID        20150309161206
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150309.200323
FW-Date         Mon Mar  9 20:03:34 EDT 2015
Bootloader      L1TC000118D0

Comment 7

[Lance（leave from Mozilla）]

(In reply to Mike Lien[:mlien] from comment #6)
> Hi Lance, could I have your help, what is the memory setting you use to
> reproduce issue.
> It looks like the memory pressure is high and I cannot reproduce it with
> v2.1 both 1G and 319MB.
> Please also attach the kernel log "adb shell dmesg" for investigation,
> thanks.
> 
> Gaia-Rev        a227b67d9ae647cc949ec1ef48ced00c80240025
> Gecko-Rev      
> https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/a61c9c3dfba7
> Build-ID        20150309161206
> Version         34.0
> Device-Name     flame
> FW-Release      4.4.2
> FW-Incremental  eng.cltbld.20150309.200323
> FW-Date         Mon Mar  9 20:03:34 EDT 2015
> Bootloader      L1TC000118D0

Hi Mike,

I have reproduced this bug on latest Flame 2.2, the Flame memory is 319MB.

Steps:
Prerequisite: You have install Twitter and log in an account.
1. Open Gallery App 
2. Tap on any photo. 
3. Tap "share picture"
4. Select "Twitter". 

Expected Result: 
4. We can enter into twitter page of editing message.

Actual Result: 
4. Twitter app is launched and device automatically comes back to Gallery.

Fail rate: 2/5
Found time:4:04
See attachment:404.mp4, dmesg.txt and logcat_404.txt

Flame 2.2 version:
Build ID               20150309002506
Gaia Revision          166491b92278dc9e648f8d49ab02d9ca00d74421
Gaia Date              2015-03-06 18:26:27
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/91b7aa6a3243
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150309.040114
Firmware Date          Mon Mar  9 04:01:25 EDT 2015
Bootloader             L1TC000118D0

Comment 8

[Lance（leave from Mozilla）]

Attachment: dmesg.txt

Comment 9

[Lance（leave from Mozilla）]

Attachment: logcat_404.txt

Comment 10

[Lance（leave from Mozilla）]

Attachment: 404.MP4

Comment 11

[Mike Lien[:mlien]]

From dmesg log, many oom occurs, change component to performance

Comment 12

[Steven Yang [:styang]]

David, would you mind checking on this? this could be a general issue on all branches.

Comment 13

[David Flanagan [:djf]]

If this is an OOM there isn't really anything I can do about it in the Gallery app.

Since the twitter app is being killed rather than the Gallery app, that says to me that the Twitter app has declared its share activity as an inline activity rather than "disposition":"window" activity. It may be possible to resolve the bug by just changing "inline" to "window" in the manifest.webapp file.  This will mean that the user will never be returned to the gallery app, but I expect that is what the twitter app does anyway.

With an inline activity, the system app tries to keep both gallery and twitter alive.  With a window activity, it tells the system that the gallery app can be killed when memory is tight.

I have no idea where the twitter app is, so I can't test this myself, but maybe someone can try that change out.

Comment 14

[bhavana bajaj [:bajaj]]

(In reply to Mike Lien[:mlien] from comment #11)
> From dmesg log, many oom occurs, change component to performance

please note, there is no active team owning performance so moving the component is not going to get any attention. Every functional team owns its own performance bugs here or should be be helping to investigate to identify the right component. Just something to keep note of in future.

Comment 15

[No-Jun Park [:njpark]]

trying out to see whether it's oom issue

Comment 16

[No-Jun Park [:njpark]]

It looks that the issue does reproduce if I have only gallery app running on the phone and executing it for the first time, and if i attempt it for the 2nd time it works properly, so it might be the case that it is not an OOM issue

Comment 17

[Michael:mtreese]

per comment 13 from David - this may be a Twitter issues. Caitlin, could you have someone from the marketplace apps team review it?

Comment 18

[Caitlin Galimidi [:c8o]]

harald - 
can your team please take a peek at this issue with Twitter? 
see comment 13 above.

Comment 19

[:Harald Kirschner :digitarald]

ni? on mellis to reproduce and to escalate this to twitter. As this isn't a blocker we don't expect it to be fixed soon.

Comment 20

[Michael Ellis]

Twitter is reworking the back-end of their mobile site currently, and therefore will not be able to spend engineering resources on a fix at this time.  Updates to their site should have rolled out at the beginning of the year, but have been delayed.  Will take another look at this bug after they finish to see if issue still persists.

Comment 21

[David Flanagan [:djf]]

I assume that this bug is about some version of twitter that we are pre-installing on the phone, for 2.2, right? So we must control the manifest file. My point in comment #13 from 2+ weeks ago is that we can probably fix this by making a one-line change to manifest.webapp. I don't think we need twitter to fix it. We can just fix our own manifest.

On the other hand, if reproducing this bug requires the user to install a third party app, I don't see how it is something that we can block on for 2.2.

Harald: note that this bug *has* been marked as a blocker for 2.2 and is assigned to you. Is it something you'll be able to work on?  If not, do you at least know where the pre-installed twitter app lives and how it gets pre-installed into builds?

Comment 22

[Didem Ersoz [:didem]]

Hi David,

I don't think that we can control the manifest file, we need to have Twitter edit it, to my knowledge. 

That said, I checked the manifest file of the Twitter app, and it has already declared the share activity as "disposition":"window". There is no usage of "inline" in their manifest at all. I copied the relevant part from the manifest below. 

"activities":{"share":{"filters":{"type":"image/*","number":1},"disposition":"window"

Given they already declared "disposition":"window", what could be the reason and potential fix for this issue?

Comment 23

[:Harald Kirschner :digitarald]

For reference, the manifest used for preload is https://mobile.twitter.com/cache/twitter.webapp . We can't expect from Twitter to make changes to reduce memory. Also if we still see this as a bug on Twitter the previous process was to not block on preloaded app bugs.

Comment 24

[David Flanagan [:djf]]

I can reproduce this on my Flame running master, and it does not seem to be an OOM at all. Twitter starts up and then immediately goes to the background somehow. If I long press the home button I can see that the gallery and twitter are both still running and that the twitter app is displaying a compose pane, with the shared image in it.

My guess is that the twitter app is doing something like calling history.back(), though I have no idea if that would actually cause the system app to go back to the previous app.  Or maybe it is incorrectly calling postResult() on the activity to indicate that it has successfully received the image?

Anyway, I'm guessing it is a twitter bug, though I can't rule out a system app window management bug.

Comment 25

[David Flanagan [:djf]]

Comment #24 was written after testing on a flame with 1gb of memory. When I convert to 319mb, I see that there are OOM issues here as well. With a big image, sometimes there is actually OOM stuff going on. I don't know that we can do anything about that, except maybe to enable some of the Tarako workarounds we had where we'd resize images before sharing them.

I'd say that the relevant issue for this bug, however, is the one that is memory independent.  And for that one, I don't know what is going on. 

This does not appear to be a Gallery bug. Sharing an image with email is exactly the same, as far as Gallery is concerned, as sharing an image with Twitter.  But it works for email and does not work for twitter. 

The twitter JS source is obfuscated, so I can't really try to debug it. I do see that it includes code to call postResult() on the activity. It is possible that doing that on a window activity like this would cause the system app to revert back to gallery like we're seeing here. But I can't see any code in the twitter app that invokes the code that calls postResult(), so I'm not confident that is what is happening.

The twitter app also has code that calls history.back(), though I can't figure out when that happens. Maybe that would somehow make the window manager go back to the gallery, but I honestly don't know what is expected to happen there.

Needinfo Alive because he should know what the Twitter app might be doing that would cause the window manager to go back to the gallery app like it does here.

Also needinfo Michael to reconsider your blocking decision on this. If it is a bug in the 3rd party twitter app, can we really block a release on it?

I'm confident that this is not a Gallery bug, so I'm changing the component. I'm changing it to Window management mostly because I don't know what the right component is for third party apps.  Alive: if you don't think this is a window management bug, please change the component again. Maybe Harald can tell us what the right component is for a bug in the Twitter app.

Comment 26

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to David Flanagan [:djf] from comment #25)
> Comment #24 was written after testing on a flame with 1gb of memory. When I
> convert to 319mb, I see that there are OOM issues here as well. With a big
> image, sometimes there is actually OOM stuff going on. I don't know that we
> can do anything about that, except maybe to enable some of the Tarako
> workarounds we had where we'd resize images before sharing them.
> 
> I'd say that the relevant issue for this bug, however, is the one that is
> memory independent.  And for that one, I don't know what is going on. 
> 
> This does not appear to be a Gallery bug. Sharing an image with email is
> exactly the same, as far as Gallery is concerned, as sharing an image with
> Twitter.  But it works for email and does not work for twitter. 
> 
> The twitter JS source is obfuscated, so I can't really try to debug it. I do
> see that it includes code to call postResult() on the activity. It is
> possible that doing that on a window activity like this would cause the
> system app to revert back to gallery like we're seeing here. But I can't see
> any code in the twitter app that invokes the code that calls postResult(),
> so I'm not confident that is what is happening.
> 
> The twitter app also has code that calls history.back(), though I can't
> figure out when that happens. Maybe that would somehow make the window
> manager go back to the gallery, but I honestly don't know what is expected
> to happen there.
> 
> Needinfo Alive because he should know what the Twitter app might be doing
> that would cause the window manager to go back to the gallery app like it
> does here.
> 
> Also needinfo Michael to reconsider your blocking decision on this. If it is
> a bug in the 3rd party twitter app, can we really block a release on it?
> 
> I'm confident that this is not a Gallery bug, so I'm changing the component.
> I'm changing it to Window management mostly because I don't know what the
> right component is for third party apps.  Alive: if you don't think this is
> a window management bug, please change the component again. Maybe Harald can
> tell us what the right component is for a bug in the Twitter app.

I cannot reproduce this.. the image is successfully attached to twitter activity and it does not go back.
The only case we are back to the gallery app is because
1. The callee invokes postResult
2. The callee invokes postError

If the callee is OOM killed we will just go back to homescreen. You could check this by adb kill $TWITTER_PID and you will see the closing transition.

So my only guess is twitter calls postError for some reason.

Comment 27

[howie [:howie]]

Based on all the findings above, this seems most likely a 3rd party app issue. Then, we should not block on this.

Comment 29

[Tony(Leave from Mozilla)]

  I can't repro this bug on latest build of Flame KK v2.6 master&v2.5&2.2 and Aries KK v2.6 master&v2.5 by the STR in comment 0. so close this bug. If anyone can repro it, please reopen again. Thanks.

Actual result: We can enter into twitter page of editing message in step 4.
Reproduce rate: 0/15.
Attachment: Aries KK_v2.6 master.3gp, logcat_1515.txt
---------------------------------------------------------------------------------
Device: Aries KK 2.6 master(Unaffected):
Build ID               20151110120047
Gaia Revision          c0482775b1526add626b170dd53a72d10bcaf07c
Gaia Date              2015-11-10 02:25:52
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/cc473fe5dc512c450634506f68cbacfb40a06a23
Gecko Version          45.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20151110.111927
Firmware Date          Tue Nov 10 11:19:35 UTC 2015
Bootloader             s1

Device: Aries KK 2.5 (Unaffected):
Build ID               20151110094357
Gaia Revision          07baf613699fa6225359c7f04825c5caeb71d424
Gaia Date              2015-11-09 21:32:50
Gecko Revision         http://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/e14287b00a514a15418dfaa89287030c588ad19d
Gecko Version          44.0a2
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20151110.090331
Firmware Date          Tue Nov 10 09:03:39 UTC 2015
Bootloader             s1

Device: Flame KK 2.6 512mb master(Unaffected):
Build ID               20151110150205
Gaia Revision          c0482775b1526add626b170dd53a72d10bcaf07c
Gaia Date              2015-11-10 02:25:52
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/cc473fe5dc512c450634506f68cbacfb40a06a23
Gecko Version          45.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20151110.182433
Firmware Date          Tue Nov 10 18:24:47 EST 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Device: Flame KK 2.5 512mb(Unaffected):
Build ID               20151109004552
Gaia Revision          cf646c52bb947af28329b0a100df91d1b1f2a907
Gaia Date              2015-11-09 02:55:50
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/4eafef5b80f8985c94c4a067f130d37513e1a581
Gecko Version          44.0a2
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20151109.041411
Firmware Date          Mon Nov  9 04:14:26 EST 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Device: Flame KK 2.2 512mb(Unaffected):
Build ID               20151110032503
Gaia Revision          885647d92208fb67574ced44004ab2f29d23cb45
Gaia Date              2015-10-07 13:05:24
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/ac5fce5a78e5
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20151110.064719
Firmware Date          Tue Nov 10 06:47:30 EST 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Comment 30

[Tony(Leave from Mozilla)]

Attachment: logcat_1515.txt

Comment 31

[Tony(Leave from Mozilla)]

Attachment: Aries KK_v2.6 master.3gp