Closed Bug 1023812 Opened 8 years ago Closed 8 years ago

[Flame][V1.4][Message]Nothing appears on the screen when edit a message go settings and back


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

Gonk (Firefox OS)
Not set


(blocking-b2g:1.4+, b2g-v1.4 verified, b2g-v2.0 verified, b2g-v2.1 verified, b2g-v2.2 verified)

2.0 S4 (20june)
blocking-b2g 1.4+
Tracking Status
b2g-v1.4 --- verified
b2g-v2.0 --- verified
b2g-v2.1 --- verified
b2g-v2.2 --- verified


(Reporter: panda67231, Assigned: alive)



(Whiteboard: bamboo)


(6 files)

Attached image 2014-06-20-17-36-32.png
Open a contact tap the message icon, tap menu the icon to go settings, tap "x" icon to back, nothing appears on the screen.
Attachment video:[VIDEO0192.mp4]
Attachment  log:[bugreport.txt]&[logcat.txt]
Attachment screenshot:[2014-06-20-17-36-32.png]
Happened time:17:35

[2.Testing Steps]: 
1. Launch Contact
2. Tap one contact
3. Tap message icon in contact information view
4. Tap upper right corner icon--> Settings
5. Tap  "x" icon to back

[3.Expected Result]: 
5. Back to contact information view.

[4.Actual Result]: 
5. Can't return to pre-view, and nothing appears on the screen

[5.Reproduction build]: 
Gaia        7709936aeb21859d1607dbd038489493803bb085
BuildID    20140522160202
Version    30.0

[6.Reproduction Frequency]: 
Always Recurrence,5/5
Attached file bugreport.txt
Attached video VIDEO0192.3gp
Attached file logcat.txt
Activity issue
Component: Gaia::SMS → Gaia::System::Window Mgmt
Flags: needinfo?(alive)
Assignee: nobody → alive
Flags: needinfo?(alive)
Julien, I don't see the setting option when I tried to contact->message, is it removed in v2.0?
Yes, it's been removed from the thread panel (it is still in the first (inbox, thread list) panel but then it can't trigger the issue on v2)

Maybe the issue reproduces when you try to add an attachment instead ? (although the pick activity type is "inline" where the settings activity type is "window")
Having a 1.4 patch now, but for 2.0 I don't think we have the same use case. Not sure how to invoke pick activity then config activity.
Nominate blocking
blocking-b2g: --- → 1.4?
Attached file 1.4 patch
QA Wanted to check 1.3.
Keywords: qawanted
blocking-b2g: 1.4? → 1.4+
Ever confirmed: true
The issue does not occur on the Flame 1.3

Environmental Variables:
Device: Flame 1.3
Build ID: 20140520094859
Gaia: a73235d23685e9898f40647cebd83b3fcbfd0117
Gecko: b637b0677e15318dcce703f0358b397e09b018af
Version: 28.0 (1.3) 
Firmware Version: v10G-2

Return back to contact information view
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
1.3 = no repro : comment 11
1.4 = patch has been submitted : comment 9
2.0 = uses a different case / process comment 6 and 7

QA-Wanted requests seem complete at this time.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Sorry, we need help to reproduce the issue in v2.0. We might need to use another application than SMS that starts the "settings" activity.
Keywords: qawanted
(In reply to Julien Wajsberg [:julienw] from comment #13)
> Sorry, we need help to reproduce the issue in v2.0. We might need to use
> another application than SMS that starts the "settings" activity.

I don't there's value to pursue analyzing this if we've got a way to fix this at this point.
Keywords: qawanted
(In reply to Jason Smith [:jsmith] from comment #14)
> (In reply to Julien Wajsberg [:julienw] from comment #13)
> > Sorry, we need help to reproduce the issue in v2.0. We might need to use
> > another application than SMS that starts the "settings" activity.
> I don't there's value to pursue analyzing this if we've got a way to fix
> this at this point.

I don't think*
As I understand it, we can reproduce on v1.4 so alive has a v1.4 specific patch.

But we don't have a mean to reproduce on v2.0 using the same STR, although the bug is maybe there too.

That's why I added qawanted again. Please remove it you think this is inappropriate.
Keywords: qawanted
I am going to provide the same fix (but maybe trivial different) for 2.0 but it's up to QA to verify it in 2.0 or not.
Attached file master patch
Attachment #8440552 - Flags: review?(timdream)
Attachment #8439073 - Flags: review?(timdream)
Issue DOES NOT occur in latest Flame 2.0 build. 

The STR in comment 0 does not lead to the same Settings page seen in 1.4 builds which confirms comment 6. 

Environmental Variables:
Device: Flame 2.0
Build ID: 20140609074621
Gaia: d283b742a12ac43ec087f45b02d3817cf7ddab69
Gecko: 68ac46c1b1f7
Version: 32.0a1 (2.0) 
Firmware Version: v10G-2

Leaving qawanted for patch review.
Flags: needinfo?(jmitchell)
Ok, I find no way to reproduce the bug using the preinstalled apps, but we can probably try to reproduce with adhoc apps, maybe UI Tests.
Issue DOES NOT reproduce when Settings App is accessed via Messages App instead of Contact App mentioned in comment 0. 

STR listed below was used on 1.4, 2.0, and 2.1 Flame builds. 

STR used to access Settings App after first using the Messages App:

1. Open Messages App> tap settings button in upper right corner> tap "settings">tap "x" in upper left corner.
2. Observe that user is taken back to Messages App, correctly. 

I could not find another way to access the "Message Settings" page in attempt to reproduce the issue described in comment 0.   

Environmental Variables:

Device: Flame 1.4
Build ID: 20140609235019
Gaia: 57c6a24f7c7d16aac132f3cecd3ff9ee8d53cf78
Gecko: 54a7aa1a0423
Version: 30.0 (1.4) 
Firmware Version: v10G-2

Device: Flame 2.0
Build ID: 20140608191038
Gaia: 12af93123c5db55212d51fe235d39f21209a1eaa
Gecko: 9305a8ec77fe
Version: 32.0a1 (2.0) 
Firmware Version: v10G-2

Device: Flame 2.1 - Master
Build ID: 20140615094714
Gaia: dfc4703bb81d1fa4f2087a1a6124b47a80a5d1de
Gecko: 80431d4fd0da
Version: 33.0a1 (2.1 - Master) 
Firmware Version: v10G-2
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Keywords: qawanted
Attachment #8439073 - Flags: review?(timdream) → review+
Comment on attachment 8440552 [details] [review]
master patch

Discussed offline. Apparently we used different approaches the similar activity-chain-handling scenario between |activityWindow.requestOpen()| and the function here so this bug needs to be fixed twice. We should unify these functions in the future.

Also, the behavior might be worthy of protecting with a integration test. I'll let the owner to decide.
Attachment #8440552 - Flags: review?(timdream) → review+
Hmm. Let's see if I could come up with an integration test tomorrow.
Target Milestone: --- → 2.0 S4 (20june)
Going to open another bug for integration test.
The issue is verified fixed in Flame 1.4, Flame 2.0, Flame 2.1, and Flame 2.2:

Environmental Variables:
Device: Flame 2.2 Master (Full flash)(KK)(319mb)
BuildID: 20141029040208
Gaia: 35e87ac4324f0f3abd93dcc70d61c9f37256a0f5
Gecko: 7e3c85754d32
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 36.0a1 (2.2 Master)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
Device: Flame 2.1 (Full flash)(KK)(319mb)
BuildID: 20141029001202
Gaia: eb0aab0f13c78c7ac378ad860e865c4b6eaf669f
Gecko: 318019f80a8e
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.0 (Full flash)(KK)(319mb)
BuildID: 20141029000205
Gaia: 9f5b6f025e528fabfcc068782cb9b492cb51a7f9
Gecko: de8cfd54bf93
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 32.0 (2.0)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Device: Flame 1.4 (Shallow flash)(JB)(319mb)
BuildID: 20140922000333
Gaia: efa2b8cb095407df942fee7732a5547c7034ef9b
Gecko: 02154a103d43
Version: 30.0 (1.4)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

When the user opens a new screen from the message app and closes it the message app returns correctly.
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.