Martin Shuman [:Marty] Reporter
	Description • 10 years ago

Description:
The user is able to stack multiple share activities, resulting in increasingly poor performance and app closure. The user can open the Gallery, select a picture, share with Messages, send to a contact, open the contact, edit the contact, change the contact picture, and crop the new picture all in one sequence (and still labeled as the single 'Gallery' app in the Task Manager), with performance steadily degrading over the course of these actions.  Trying to save this cropped picture to the contact will result in all the apps closing out and the user being returned to the Homescreen.

Note: If user first opens Camera instead of Gallery, and takes a new picture before sharing with Messages (and continuing the the rest of the repro steps) the apps will not close out back to homescreen, but performance will similarly degrade, and the cropped picture will fail to be applied to the contact.

Repro Steps:
1) Update a Flame device to BuildID: 20150108010221
2) Ensure there is already a contact (with picture) on the device, and at least one picture in the Gallery
3) Open the Gallery app and select a picture.
4) Select the 'Share' icon and choose Messages
5) Press the '+' icon in the recipient field and select a contact
6) Send the Message
7) Select the Contact name from the Header field and chose 'View Contact'
8) Tap the 'Edit Contact' icon
9) Tap 'Edit Picture', choose 'Change photo,' and select Gallery
10) Select a picture, crop the size of the photo, and select 'Done'

  
Actual:
Performance slows down when selecting a picture from the gallery and cropping the photo.  All apps close out to Homescreen after selecting 'Done'
  
Expected: 
Performance remains smooth and constant throughout.  Apps do not close out, but continue to function properly.
  
Environmental Variables:
Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
BuildID: 20150108010221
Gaia: d4dac29613076bdba3cb8adc217deadb08a2ac20
Gecko: 70de2960aa87
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 37.0a1 (2.2 Master)
Firmware: V18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
  
Note: This issue occurs on both v188-1 and v18D bases
  
Repro frequency: 7/7
See attached: video clip, logcat

---------------------------------------------------------------------

This issue does NOT occur on Flame 2.1.
User is able to navigate to Gallery > Messages > Contacts > Edit Contact > Change Picture, Crop a photo and update the contact picture successfully.

Environmental Variables:
Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20150108001214
Gaia: ed2e278753e8c9301ba322dcf2c3591f5928408d
Gecko: 127a0ead5f83
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 34.0 (2.1)
Firmware: V18D
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

	Peter Bylenga [:PBylenga]
	Comment 1 • 10 years ago

NI on Gallery component owner for nomination decision.  Edge case that reveals performance regression.

	No-Jun Park [:njpark]
	Comment 2 • 10 years ago

Reason for blocking:
I think a noticeable performance degradation (a regression too,) while doing a common use case activity is a blocker.

	Thinker Li [:sinker]
	Comment 3 • 10 years ago

I think this should be fixed at UX side, instead of Gecko or application.  Since you always could build an UX of infinite levels of stacking, we need UX to take care memory usage too, especially, for low-end devices.

	Bobby Chien
	Comment 4 • 10 years ago

david, could you help to comment gallery behavior?

	David Flanagan [:djf]
	Comment 5 • 10 years ago

I think that this is simply a matter of us running out of memory. The reporter does not specify that this is a 319mb flame, but I suspect it is, and I suspect that if it was tested on a 512mb flame, this bug would not reproduce. It would be interesting to know how much memory the device has and see the output of `adb shell b2g-ps` before the crash occurs.

Note also that the bug description in incorrect in that there is only one share activity involved. Gallery shares an image with Messages. The messages does a View activity (or something) with Contacts.  And Contacts does a Pick activity with Gallery. It doesn't really matter that they aren't all share activities: there are still lots of apps held open.

I see in apps/sms/manifest.webapp, that it declares its share activity as "inline" rather than "window". This means that the Gallery app is kept alive. But if the messages app does not return to the Gallery app after the text is sent, then this is wrong.  

To fix this, I think we should modify the messages app to use window disposition instead of inline disposition.

	David Flanagan [:djf]
	Comment 6 • 10 years ago

Needinfo Julien to see if the suggestion above is possible.

	Julien Wajsberg [:julienw]
	Comment 7 • 10 years ago

Gabriele has some plan to make this better (bug 892371). In the mean time we plan to remove the "contact" activity launcher when the SMS app is itself in an activity (see bug 1124944). So I think this should effectively fix part of this bug.

But I don't want to change the activity disposition to window...

Note that the messages app does return to the Gallery app when the user presses the top left "cross" button. But we don't want to return right away because the user might want to send a follow-up message.

	Stephany Wilkes
	Comment 8 • 10 years ago

Triage is blocking based on regression status.

	Bobby Chien
	Comment 9 • 10 years ago

any update on this?

	Julien Wajsberg [:julienw]
	Comment 10 • 10 years ago

We fixed bug 1124944 in SMS. I don't know if this fixes this issue, I'll let you decide.

	Gabriele Svelto [:gsvelto]
	Comment 11 • 10 years ago

As Julien mentioned bug 892371 is going to help in this scenario and it should be part of 2.2.

	Bobby Chien
	Comment 12 • 10 years ago

Gabriele, could you help to take this bug?

	Gabriele Svelto [:gsvelto]
	Comment 13 • 10 years ago

Once bug 892371 lands this should be fixed for good; expect a working patch for that bug later today. I'll test it and report here.

	Julien Wajsberg [:julienw]
	Comment 14 • 10 years ago

Can we just check this is still an issue now that bug 1124944 is fixed?
I think the scenario is not possible anymore.

	Brogan Zumwalt [Inactive]
	Comment 15 • 10 years ago

Unable to reproduce bug

Step 7 from STR in comment 0 no longer possible as tapping header on this shared message screen does not open context menu (tapping header does nothing.)

Device: Flame 2.2
Build ID: 20150305002528
Gaia: 89af288bad6751248ff84504fa898206fee127fe
Gecko: 6d8d294aa8f3
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

	KTucker [:KTucker][Inactive 3/4/2016]
	Comment 16 • 10 years ago

Closing this as worksforme since this is no longer possible.