947092 - [fugu][buri][sms]View/Listen attachment in SMS is stopped when send sms to background

Status: RESOLVED WONTFIX

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

Description

[Peipei Cheng (needinfo if you need my action)]

This can be reproduced on both V1.2 and V1.3.
STR:
1. Create a SMS
2. Add a picture to the attachment
3 [review]. Tap on the picture, and select 'View'. View picture page appears.
4. Tap on Home button and send SMS to backend
5. bring SMS to frontend
   --> The context menu page shows.

[expected] we should return to view picture page.

Music attachment also has the same problem. 

buri v1.2 build

Gaia      0659f16b9790b1cf9eba4d80743fcc774d2ffe3a                         
Gecko                                                                      
http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/af2c7ebb5967         
BuildID   20131205004003                                                   
Version   26.0                                                             
ro.build.version.incremental=eng.archermind.20131114.105818

Comment 1

[Julien Wajsberg [:julienw]]

(filed bug 947118 on bugzilla for the wrong autolink in comment 0)

Comment 2

[Julien Wajsberg [:julienw]]

Window management issue.

Comment 3

[Preeti Raghunath(:Preeti)]

Please take a look for 1.3 blocking

Comment 4

[Preeti Raghunath(:Preeti)]

Given that the user is able to recover, will not block on it for 1.3.

Comment 5

[Stephany Wilkes]

Flagging Ayman as an FYI and to give him a chance to say otherwise if need be. :)

Comment 6

[Jason Smith [:jsmith]]

See the above comment - we are not going to block on this.

Comment 7

[ayman maat :maat]

I agree this is not a blocker as the user can recover, but we should aim to fix it as soon as possible

Comment 8

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Alive,

Is this something we can take on v1.4 cycle? What do we actually need in this user flow?

Comment 9

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

We could do this before gecko fix:

Implement ActivityWindowManager and keep at most one inline activity alive even we send the activity opener to background.
If there's some other app trying to open a new inline activity, kill the living activity.

P.S. The gecko issue is we cannot have more than one activity page of same URL because system message is always sending to the first instance. They maintain the instances by app manifestURL now.

Comment 10

[Ivan Tsay (:ITsay)]

Hi Alive,

Do you know if there is related gecko bug for addressing this issue.

Minus this bug for now since it is not suggested using workaround in gaia before it is fixed in gecko. It is the double effort to do it again after the issue is fixed in gecko

Comment 11

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

It's bug 931339.

BTW it's not workaround but some enhancement. The gecko bug forbids us to open more than one activities with same origin but we could still keep more than one activities carefully.

Comment 12

[BMO Automation]

Firefox OS is not being worked on