Closed Bug 1018035 Opened 6 years ago Closed 6 years ago
.4][SMS]No cursor display when tap the message edit box .
* 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 https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/95be84248033 - 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?
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
QA Contact: ekramer
Does this happen on 1.3?
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Seems like something basic to an input field that's not working here.
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 Gecko https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/a8bb6b76696b BuildID 20140611000202 Version 30.0 ro.build.version.incremental=eng.vagrant.20140528.073244 ro.build.date=Wed 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? Thanks
Assignee: nobody → felash
Able to repro on today's Flame 2.0. Youtube clip has been added. Build ID: 20140611091244 Gecko: https://hg.mozilla.org/releases/mozilla-aurora/rev/0c0effd600c4 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?]
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
Please make sure you flag Joshua down when QA requests are finished.
Flags: needinfo?(ckreinbring) → needinfo?(jmitchell)
Regression window: Last Working Build ID: 20140510183010 Gecko: https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/ec24f847e7c0 Gaia: 17fb44880e95bc7ae363a609d811bf5a9a067b5b Platform Version: 30.0 Firmware Version: V10g-2 First Broken Build ID: 20140512123005 Gecko: https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/cc1987fe9ee4 Gaia: 69bd6293c3e138258257af37a33765997e49bd6e Platform Version: 30.0 Firmware Version: V10g-2 Last Working Gaia / First Broken Gecko - OK Gaia: 17fb44880e95bc7ae363a609d811bf5a9a067b5b Gecko: https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/cc1987fe9ee4 First Broken Gaia / Last Working Gecko - Fail Gaia: 69bd6293c3e138258257af37a33765997e49bd6e Gecko: https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/ec24f847e7c0 Gaia push log: https://github.com/mozilla-b2g/gaia/compare/17fb44880e95bc7ae363a609d811bf5a9a067b5b...69bd6293c3e138258257af37a33765997e49bd6e
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+]
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.
Still need to update unit tests.
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
(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 ;)
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.
I pushed to v1.4 because a v1.4-specific patch was needed. NI me to push to v2.0.
Whiteboard: torch → torch, [not-part-of-initial-sprint]
You need to log in before you can comment on or make changes to this bug.