Closed Bug 1119459 Opened 10 years ago Closed 9 years ago

[Performance][Gallery] Stacking Share activities from Gallery, Messages and Contacts results in very slow performance and app closure.


(Firefox OS Graveyard :: Performance, defect)

Gonk (Firefox OS)
Not set


(blocking-b2g:2.2+, b2g-v2.1 unaffected, b2g-v2.2 affected)

blocking-b2g 2.2+
Tracking Status
b2g-v2.1 --- unaffected
b2g-v2.2 --- affected


(Reporter: Marty, Unassigned)




(Keywords: regression, Whiteboard: [2.2-Daily-Testing])


(1 file)

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'

Performance slows down when selecting a picture from the gallery and cropping the photo.  All apps close out to Homescreen after selecting 'Done'
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
NI on Gallery component owner for nomination decision.  Edge case that reveals performance regression.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga) → needinfo?(npark)
Whiteboard: [2.2-Daily-Testing]
Reason for blocking:
I think a noticeable performance degradation (a regression too,) while doing a common use case activity is a blocker.
blocking-b2g: --- → 2.2?
Flags: needinfo?(npark)
tracking-b2g: --- → +
Flags: needinfo?(tlee)
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.
Flags: needinfo?(tlee)
david, could you help to comment gallery behavior?
Flags: needinfo?(dflanagan)
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.
Flags: needinfo?(dflanagan)
Needinfo Julien to see if the suggestion above is possible.
Flags: needinfo?(felash)
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.
Flags: needinfo?(felash)
Triage is blocking based on regression status.
blocking-b2g: 2.2? → 2.2+
any update on this?
Depends on: 892371
We fixed bug 1124944 in SMS. I don't know if this fixes this issue, I'll let you decide.
As Julien mentioned bug 892371 is going to help in this scenario and it should be part of 2.2.
Gabriele, could you help to take this bug?
tracking-b2g: + → ---
Flags: needinfo?(gsvelto)
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.
Flags: needinfo?(gsvelto)
Can we just check this is still an issue now that bug 1124944 is fixed?
I think the scenario is not possible anymore.
Keywords: qawanted
QA Contact: bzumwalt
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
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawanted
Closing this as worksforme since this is no longer possible.
Closed: 9 years ago
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Resolution: --- → WORKSFORME
Depends on: 1144132
You need to log in before you can comment on or make changes to this bug.