Closed Bug 1144814 Opened 5 years ago Closed 5 years ago
[RTL][Email] Special characters typed using English keyboard appear at far left of typed string
Description: With language set to Arabic, typing a special character (e.g. ".", "/", ":", "@", etc.) in the body of an email while using the English keyboard, the special character is placed to the left of alphanumeric characters. Repro Steps: 1) Update a Flame to 20150317062432 2) Set language to Arabic 3) Launch email (set up account if not already logged in) 4) Compose new message 5) Type a combination of alphanumeric and special characters in body of email Actual: The special characters are placed to the far left of typed alphanumeric characters. Expected: Using English keyboard, special characters are placed to the far right (at cursor) when typing a combination of special and alphanumeric characters. Environmental Variables: Device: Flame 3.0 Build ID: 20150317073344 Gaia: 738987bd80b0ddb4ccf853855388c2627e19dcc1 Gecko: 008b3f65a7e0 Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b Version: 39.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0 Repro frequency: 3/3, 100% See attached: Youtube video: http://youtu.be/Z8i80eENZqw
Issue DOES reproduce on Flame 2.2 The special characters are placed to the far left of typed alphanumeric characters. Device: Flame 2.2 Build ID: 20150318002504 Gaia: 306772a58335ac4cad285d27c3805090a8cc6886 Gecko: a6f5f4035ea5 Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b Version: 37.0 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage?][rtl-impact] → [QAnalyst-Triage+][rtl-impact]
That's definitely bad. Nominating
blocking-b2g: --- → 2.2?
Priority: -- → P1
Relevant bug & comment: https://bugzilla.mozilla.org/show_bug.cgi?id=1137021#c8
Test case has been added in moztrap: https://moztrap.mozilla.org/manage/case/15287/
Hi Lancy, Can you verify whether the issue is fixed after bug 1137021 fixed? Thanks
blocking-b2g: 2.2? → 2.2+
Hi Josh, This issue still exists on latest build of Flame 2.2 and Flame 3.0. Type a combination of alphanumeric and special characters in body of email, the special characters are placed to the far left of typed alphanumeric characters. See attachment: Verify1_Flame2.2&3.0_Fail.mp4 Reproducing Rate:10/10 Flame 2.2 build (Affected): Build ID 20150325162500 Gaia Revision 2d42a7c1d99472780e3aeb2e16d7cb0a4adbd222 Gaia Date 2015-03-25 20:46:52 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/ebb742bfe1a4 Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150325.200218 Firmware Date Wed Mar 25 20:02:30 EDT 2015 Bootloader L1TC000118D0 Flame 3.0 build (Affected): Build ID 20150325160204 Gaia Revision 508b8d48fb5ecf08bf0e5b4fef42bc48b770e7f2 Gaia Date 2015-03-25 16:54:53 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/f40ee067d081 Gecko Version 39.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150325.191758 Firmware Date Wed Mar 25 19:18:07 EDT 2015 Bootloader L1TC000118D0
Flags: needinfo?(yulan.zhu) → needinfo?(jocheng)
Dear Ted, Could you please help to check this issue? This is similar to bug 1137021. Thanks!
Flags: needinfo?(jocheng) → needinfo?(tclancy)
Hi Dylan, Could you help to find someone to take this bug as FC is coming? Thanks!
I don't think this is actually a bug. Because this field isn't a dedicated URL field, or phone number field, or email address field, we have no way of knowing what the user intends to type. So if the user types "ted.", we have no way of knowing that that's the start of an email address. It's possible that they just want to end the sentence with "ted" followed by a full stop (period), in which case the full stop should appear on the left. That's what happens right now, and I think it's the best behaviour we can expect.
Resolving as invalid based on comment #9.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.