Closed Bug 1018035 Opened 6 years ago Closed 6 years ago

[Flame][v1.4][SMS]No cursor display when tap the message edit box.


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

Gonk (Firefox OS)
Not set


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

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


(Reporter: greatwall2686, Assigned: julienw)




(Keywords: regression, Whiteboard: torch, [not-part-of-initial-sprint])


(3 files)

* Description:
  No cursor display when tap the message edit box.

* Reproduction steps:
  1. Tap message icon to launch
  2. Tap "+" to compose a message
  3. Tap edit box

* Expected result:
  The cursor should be display in edit box.

* Actual result:
  There is no cursor display.

* Reproduction build:(Buri - Firefox OS V1.4 inside)
 - Gaia      17b102ee8d9a724b62285547cc5f1c5d30bfb01c
 - Gecko
 - BuildID   20140520000201
 - Version   30.0

* Reproduction Frequency
  - 100%
update steps:
tap an call hostory to send SMS, tap the edit box, the cursor cannot display.
In bug 1014420 comment 1, Noemi could not reproduce in v1.4. Can we try with a newer build?
Keywords: qawanted
This issue DOES repro on a newer Flame 1.4 build.

Environmental Variables:
Device: Flame 1.4
Build ID: 20140609000201
Gaia: 8b239e41bbd85aa7b6a2c5d388e775ba7de6fb2b
Gecko: e3f85877db29
Version: 30.0 (1.4) 
Firmware Version: v10G-2
Keywords: qawanted
QA Contact: ekramer
Does this happen on 1.3?
Ever confirmed: true
Keywords: qawanted
This issue does NOT repro on 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
Keywords: qawanted
Seems like something basic to an input field that's not working here.
blocking-b2g: --- → 2.0?
blocking-b2g: 2.0? → 1.4?
Summary: [Flame][v1.4][Wifi]No cursor display when tap the message edit box. → [Flame][v1.4][SMS]No cursor display when tap the message edit box.
Actually, the composer's input is made of contenteditable div. And contenteditable stuff have lots of subtle issues that need work arounds :)

Waiting on the regression window.
Seems like a basic use case isn't working. Bad UX too hence blocking for 1.4
blocking-b2g: 1.4? → 1.4+
So, I don't reproduce on any device. I tried Flame master (latest), Flame v1.4 (latest), Peak v1.4 (3 weeks old), Hamachi master (recent), Dolphin master (recent), Dolphin v1.4 (latest).

Here is the version I used to flash Flame v1.4:
Gaia      d1cf95dc5e8b2f52148487291318542f1396608e
BuildID   20140611000202
Version   30.0 May 28 07:33:48 UTC 2014

I don't know the Firmware version though.

Can QA double check on the newest firmware for Flame too? Can I have a video of the bug happening?

Assignee: nobody → felash
Keywords: qawanted
QA Contact: ekramer → ckreinbring
Able to repro on today's Flame 2.0.  Youtube clip has been added.

Build ID: 20140611091244
Gaia: a0f9f1f41a436daad8a249ce85df80a81a5ba2d5
Platform Version: 32.0a2
Firmware Version: V10g-2
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
QA: thanks, but the video doesn't do what the description in comment 0 is doing: simply launching the Messages app. It shows the issue reproduce with STR in comment 1 though which is a good information (and I admit I didn't try this).

Can you try again with the description in comment 0 please?
Flags: needinfo?(ckreinbring)
Attempting with just the steps in comment 0, I was unable to repro with today's Flame 2.0 and 1.4.  The cursor appeared when the Messages textbox was tapped.

BuildID: 20140611000202
Gaia: d1cf95dc5e8b2f52148487291318542f1396608e
Gecko: a8bb6b76696b
Version: 30.0
Firmware Version: V10G-2
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
Flags: needinfo?(ckreinbring)
Please make sure you flag Joshua down when QA requests are finished.
Flags: needinfo?(ckreinbring)
Flags: needinfo?(ckreinbring) → needinfo?(jmitchell)
Regression window:
Last Working
Build ID: 20140510183010
Gaia: 17fb44880e95bc7ae363a609d811bf5a9a067b5b
Platform Version: 30.0
Firmware Version: V10g-2

First Broken
Build ID: 20140512123005
Gaia: 69bd6293c3e138258257af37a33765997e49bd6e
Platform Version: 30.0
Firmware Version: V10g-2

Last Working Gaia / First Broken Gecko - OK
Gaia: 17fb44880e95bc7ae363a609d811bf5a9a067b5b

First Broken Gaia / Last Working Gecko - Fail
Gaia: 69bd6293c3e138258257af37a33765997e49bd6e

Gaia push log:
Regression window provided -  The initial window had a VERY small push-log so I did not have the tester proceed to a secondary window.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Broken by bug 1003384.
Blocks: 1003384
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
I highly doubt that bug 1003384 broke this.
Gonna investigate on my side, with the STR in comment 1.
I did a bisect from the pushlog, and the failing patch is bug 999286.

And actually, I reproduce on a current v1.3 (on a Inari). I don't know why we don't see it in comment 5, my guess is that the tester used the STR from comment 0.
Blocks: 999286
No longer blocks: 1003384
Attached file github PR for master
Still need to update unit tests.
Attached file github PR for v1.4
Comment on attachment 8439400 [details] [review]
github PR for master

I couldn't reproduce on a simpler testcase to report the bug to gecko, so here is only the workaround because sometimes we just need to move forward.

There still is an issue on master: when it's an activity, the iframe itself has not the focus and as a result we don't have the focus in the activity. I don't know yet if it works in v1.4. I'll file a separate bug for this.
Attachment #8439400 - Flags: review?(azasypkin)
Ok, the bug is not in v1.4 :)
Filed bug 1025169.
Comment on attachment 8439400 [details] [review]
github PR for master

Looks good to me, just left tiny nit at github, thanks! But travis is red for some reason.
Attachment #8439400 - Flags: review?(azasypkin) → review+
Updated both pull requests, waiting for Travis.
v1.4: 4b3428e85b428e577a0f96cba6121c4ca1c91f8a
master: 23245b524afd918c6110d675d8b175556368179e
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.0 S4 (20june)
(In reply to Julien Wajsberg [:julienw] from comment #26)
> v1.4: 4b3428e85b428e577a0f96cba6121c4ca1c91f8a
> master: 23245b524afd918c6110d675d8b175556368179e

Missing a v2.0 uplift there?
Yep Ryan, I was expecting you ;)
Flags: needinfo?(ryanvm)
If you're already pushing to v1.4 at the same time, might as well take care of v2.0 while you're at it, IMO. BTW, we generally recommend that you *not* push to release branches at the same time as master, fwiw. Makes backouts a bigger PITA should one become necessary.
Flags: needinfo?(ryanvm)
I pushed to v1.4 because a v1.4-specific patch was needed.

NI me to push to v2.0.
Flags: needinfo?(felash)
Blocks: sms-sprint-3
Whiteboard: torch → torch, [not-part-of-initial-sprint]
You need to log in before you can comment on or make changes to this bug.