Closed Bug 905075 Opened 11 years ago Closed 11 years ago

[Messages] Last view briefly shows the next time the Messages app is opened

Categories

(Firefox OS Graveyard :: Gaia::SMS, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: sync-1, Assigned: rwaldron)

References

Details

(Whiteboard: c=)

Attachments

(2 files, 2 obsolete files)

24.65 KB, image/png
Details
7.73 MB, application/octet-stream
Details
AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.184 Firefox os v1.1 Mozilla build ID:20130806071254 DEFECT DESCRIPTION: the MMS briefly shows the next time the Messaging app is opened REPRODUCING PROCEDURES: If a MMS has been created and the Message app is killed in the "Multitasking" flow, the MMS briefly shows the next time the Messaging app is opened->KO EXPECTED BEHAVIOUR: the MMS shouldn't briefly show the next time the Messaging app is opened ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: Mid REPRODUCING RATE: 5/5 For FT PR, Please list reference mobile's behavior:
blocking-b2g: --- → leo?
can you attach a video? thanks
Flags: needinfo?(sync-1)
Assignee: nobody → waldron.rick
Flags: needinfo?(sync-1)
Summary: [Buri]the MMS briefly shows the next time the Messaging app is opened → [Buri][shira]the MMS briefly shows the next time the Messaging app is opened
Attached image 2013-08-09-15-35-02.png
Summary: [Buri][shira]the MMS briefly shows the next time the Messaging app is opened → [Buri][TOR]the MMS briefly shows the next time the Messaging app is opened
Hopefully someone can confirm/refute: isn't this caused by the screenshot taken when the app was minimized? Shouldn't the screenshot be discarded?
Not critical enough for blocking status, adding to sprint backlog.
blocking-b2g: leo? → -
Whiteboard: c=
(In reply to lsblakk@mozilla.com [:lsblakk] from comment #4) > Not critical enough for blocking status, adding to sprint backlog. 1. If I delete some privacy messages in sms app, 2. and I kill the app now(not tap back button) in the "Multitasking" flow, 3. and then, someone else may use my phone, he open the sms app again, it will display the screen which the privacy messages are not deleted firstly, the message I don't want to show him. This situation is very embarrassing ah.
(In reply to xiupinglong from comment #5) > (In reply to lsblakk@mozilla.com [:lsblakk] from comment #4) > > Not critical enough for blocking status, adding to sprint backlog. > > 1. If I delete some privacy messages in sms app, > 2. and I kill the app now(not tap back button) in the "Multitasking" flow, > 3. and then, someone else may use my phone, he open the sms app again, it > will display the screen which the privacy messages are not deleted firstly, > the message I don't want to show him. > This situation is very embarrassing ah. I just tried this and there is no way to reproduce what you just described. Can you provide a video that illustrates the steps to reproduce—thanks
Summary: [Buri][TOR]the MMS briefly shows the next time the Messaging app is opened → [Messages] Last view briefly shows the next time the Messages app is opened
Attached file VID_0003.3gp (obsolete) —
comment 7 doesn't seem to have the correct video. can you attach the correct one? thanks
Flags: needinfo?(longxiuping)
Attached file 905075.3gp (obsolete) —
Attachment #792009 - Attachment is obsolete: true
Flags: needinfo?(longxiuping)
Although not cratical but many apps have the same problem -- dialer, contacts(almost all hosted apps), it's really impact performance and not good user experience. Mark leo? again.
blocking-b2g: - → leo?
(In reply to xiupinglong from comment #9) > Created attachment 792057 [details] > 905075.3gp Am I missing something? There is no flash of old display in this video.
hi Jack, did you upload the correct video? does not see the symptom described in the new video. Thanks
Flags: needinfo?(liuyongming)
koi? moving to future versions
blocking-b2g: leo? → koi?
hi Joe, the video attached in comment#9 is correct.
Flags: needinfo?(liuyongming)
(In reply to Jack Liu from comment #14) > hi Joe, the video attached in comment#9 is correct. But it doesn't show anything abnormal?
(In reply to Rick Waldron from comment #15) > (In reply to Jack Liu from comment #14) > > hi Joe, the video attached in comment#9 is correct. > > But it doesn't show anything abnormal? reproduce steps: 1. when I delete a message, 2. and kill the sms app, 3. restart the sms app again, the deleted message is showed firstly, and then after the sms thread rendered ok the message will disappear? -> abnormal, the sms app should not show the last time thread with the deleted message firstly, it should display the update thread message when restart the sms app.
Attached file SMS_905075.mp4
Provide more clear video
Attachment #792057 - Attachment is obsolete: true
And in the video 00:17, when the sms app restart it show the message deleted firstly, 00:18 is a white screen, 00:19 is a rendered ok screen not contains the deleted message.
the behavior in master should already be changed for the app loading transition. koi+ to make sure
blocking-b2g: koi? → koi+
(In reply to xiupinglong from comment #16) > (In reply to Rick Waldron from comment #15) > > (In reply to Jack Liu from comment #14) > > > hi Joe, the video attached in comment#9 is correct. > > > > But it doesn't show anything abnormal? > > reproduce steps: > 1. when I delete a message, > 2. and kill the sms app, > 3. restart the sms app again, the deleted message is showed firstly, and > then after the sms thread rendered ok the message will disappear? -> > abnormal, the sms app should not show the last time thread with the deleted > message firstly, it should display the update thread message when restart > the sms app. I see it now in the video—the value of "body" property of a thread object will update that line, but since it only happens when the app is brought into view it still shows the old message.
Depends on: 893838
So, this is triggered by the screenshot logic that is really buggy on 1.1, but was redone in 1.2. Could the reporter check everything happens as expected on master ?
No longer depends on: 893838
Flags: needinfo?(sync-1)
Keywords: qawanted
No longer depends on: 893838
(reporter or QA)
(In reply to Julien Wajsberg [:julienw] from comment #21) > So, this is triggered by the screenshot logic that is really buggy on 1.1, > but was redone in 1.2. > > Could the reporter check everything happens as expected on master ? Could you tell me what the pull request or patch for this issue? Thanks!
I think there is not a single patch for this, but maybe :alive would know more.
Flags: needinfo?(alive)
I don't remember the patch removing screenshots, but there's indeed no this function in master. Shouldn't be koi+.
Flags: needinfo?(alive)
:alive> you mean the bug is not on master and this bug is "worksforme" for master then ?
blocking-b2g: koi+ → ---
(In reply to Julien Wajsberg [:julienw] from comment #26) > :alive> you mean the bug is not on master and this bug is "worksforme" for > master then ? Indeed.
(In reply to Alive Kuo [:alive] from comment #27) > (In reply to Julien Wajsberg [:julienw] from comment #26) > > :alive> you mean the bug is not on master and this bug is "worksforme" for > > master then ? > > Indeed. So there is not a patch separately for removing screenshots, and when launch an app now is replaced by the app icon with a black background?
Yes they are probably different patches but they were made a long time ago, that's why it's difficult to find them back. Moreover, it's possible that the original patch had bugs and thus follow-up patches are needed to make it work correctly. That's why it's difficult to give you the specific patch that made this happening. Why do you need this specific information ? If you really need it we can try to find this information but this takes time.
Since it is solved on master, I think if we have the patch for this, we can try to apply it on v1.1. Thank you for your strongly support!
Flags: needinfo?(sync-1)
(In reply to xiupinglong from comment #30) > Since it is solved on master, I think if we have the patch for this, we can > try to apply it on v1.1. Thank you for your strongly support! I don't recommend to pick this patch to 1.1, It's dangerous to do this right now.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: