Closed Bug 1226419 Opened 9 years ago Closed 9 years ago

Cursor disappear when reopening messages app again

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.6+, b2g-v2.2 unaffected, b2g-v2.5 unaffected, b2g-master affected)

RESOLVED WORKSFORME
blocking-b2g 2.6+
Tracking Status
b2g-v2.2 --- unaffected
b2g-v2.5 --- unaffected
b2g-master --- affected

People

(Reporter: vbelonenko, Unassigned)

References

()

Details

(Whiteboard: [2.5-Daily-Testing][Spark])

Attachments

(1 file)

Description: When selecting 'To:' field in the messages app and going home and selecting messages app again Cursor disappears. Repro Steps: 1) Update a Aries to 20151119162551 2) Open Message app 3) Select 'TO:' field and cursor is on 4) Select home button 5) Select Message app 6) Observe that cursor disappears. Actual: When selecting message app again cursor disappears Expected: Selecting Message app for second time, the cursor should not disappear. Environmental Variables: Device: Aries Master 2.6 kk full flash Build ID: 20151119162551 Gaia: ffaade435bb9c3005fd6c9b7ee1cd17b90e08cbf Gecko: a523d4c7efe2f43dd6b25a176c07b729918d550f Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56 Version: 45.0a1 (Master) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0 Repro frequency: 3.3 See attached: video clip and logcat
This issue does not occur on Flame 2.6, Flame 2.5, Flame 2.2 Result: Selecting Message app for second time, the cursor did not disappear. Environmental Variables: Device: Flame 2.6 kk full flash Build ID: 20151119030229 Gaia: cba7e4b86361af31b153cfebaf99900e0b860f7b Gecko: 1d6155d7e6c91fa5ec1ef6927f3d3a044187896d Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a Version: 45.0a1 Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0 Environmental Variables: Device: Flame 2.5 kk full flash Build ID: 20151119161153 Gaia: 28d63cf3bdc4417f7ad8cab2230f096bf9f6d3b5 Gecko: 497118efc1414c2825a8bd17b38721888c3875ca Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a Version: 44.0a2 Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0 Environmental Variables: Device: Flame 2.2 kk full flash Build ID: 20151119002503 Gaia: b12374ef1457cab0ae9b330171a373c7160c031a Gecko: 8c712917dc6f Gonk: bd9cb3af2a0354577a6903917bc826489050b40d Version: 37.0 (2.2) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Keywords: regression
Summary: Cursor disappear when reopening messages app again. → Cursor disappear when reopening messages app again
[Blocking Requested - why for this release]: Functional regression from 2.5
blocking-b2g: --- → 2.6?
Should be easy to find a regression window.
Side note: Having a Gij test looks doable, in order to prevent another occurrence of this regression.
QA Contact: sleedavid
QA Contact: sleedavid
Is this the same issue? The steps I used to Repro the results were different. STR: 1) Start Message app. 2) Press SHB to put app into background. 3) Observe Message app in background, and tap to bring to foreground. Actual Result: Message app expands with no cursor and NO keyboard. Expected Result: Message app expands with cursor and keyboard already presented. Environmental Variables: Device: Aries 2.6 BuildID: 20151120133504 Gaia: 94a821b49f4dca3f9321cd80e13c44c4a6696952 Gecko: ec628289d8b4ed310463a0729c3e60a7798dfcac Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56 Version: 45.0a1 (2.6) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0
I can't repro this bug on reported build. Repro rate is 0 out of ~30. I can repro comment 5, though comment 5 steps is wrong (comment 5 is actually entering task manager at step 2). We'll look into bugging it separately. For this bug it is a no repro. Device: Aries 2.6 BuildID: 20151119162551 Gaia: ffaade435bb9c3005fd6c9b7ee1cd17b90e08cbf Gecko: a523d4c7efe2f43dd6b25a176c07b729918d550f Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56 Version: 45.0a1 (2.6) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0
The results from the steps comment 5 are different than the results I view in the video linked. In the original STR the keyboard will briefly show up and be dismissed. In comment 5 the keyboard never activates. I was also unable to reproduce the STR from comment 0 after 25 attempts so there must be some prerequisite step to get this to occur. Removing regression-window wanted tag and the regression tag until we get more complete steps and can verify if it is actually a regression.
Vladimir please attempt to reproduce this issue again.
Flags: needinfo?(vbelonenko)
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
See Also: → 1226721
(In reply to Pi Wei Cheng [:piwei] from comment #6) > I can't repro this bug on reported build. Repro rate is 0 out of ~30. > > I can repro comment 5, though comment 5 steps is wrong (comment 5 is > actually entering task manager at step 2). Because you're longpressing it, likely ? Note that both flows do actually trigger the same code in the System app, so I'm sure this is the same bug.
Look at the video https://www.youtube.com/watch?v=mmBOwnB2_AQ In the video they're not long pressing the home button. And after going back to Messages the keyboard flashes up and disappears.
(In reply to Pi Wei Cheng [:piwei] from comment #10) > Look at the video https://www.youtube.com/watch?v=mmBOwnB2_AQ > In the video they're not long pressing the home button. And after going back > to Messages the keyboard flashes up and disappears. That's not what I'm saying; I'm commenting "(comment 5 is actually entering task manager at step 2)" but I don't understand how you do this with the steps in comment 5.
(In reply to Julien Wajsberg [:julienw] from comment #11) > That's not what I'm saying; I'm commenting "(comment 5 is actually entering > task manager at step 2)" but I don't understand how you do this with the > steps in comment 5. Well, I asked Sxean, in comment 5, who was sitting next to me what he did exactly because I didn't understand his steps either. I then understood after he showed it to me in person.
Regression, making blocker
blocking-b2g: 2.6? → 2.6+
I couldn't reproduce this bug on latest build id. Environmental Variables: Device: Aries Master 2.6 kk full flash Build ID: 20151207143802 Gaia: 24ed003a53a81f63367e265fa7117cbe7d23d4c8 Gecko: 59bc3c7a83de7ffb611203912a7da6ad84535a5a Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56 Version: 45.0a1 (Master) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0
Flags: needinfo?(vbelonenko) → needinfo?(jmercado)
Reporter can't reproduce this either anymore. Resolving this as WFM for now. Please reopen if this issue is seen again.
Flags: needinfo?(jmercado)
Keywords: steps-wanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+][non-reproducible]
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: