Last Comment Bug 770291 - Holding backspace may delete text both in front of and behind the cursor
: Holding backspace may delete text both in front of and behind the cursor
Status: RESOLVED WORKSFORME
: dataloss
Product: Firefox for Android
Classification: Client Software
Component: Keyboards and IME (show other bugs)
: Trunk
: ARM Android
: P2 normal with 2 votes (vote)
: ---
Assigned To: Jim Chen [:jchen] [:darchons]
:
: Jim Chen [:jchen] [:darchons]
Mentors:
http://w3schools.com/html/tryit.asp?f...
: 806188 (view as bug list)
Depends on: 769520
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-02 12:26 PDT by Michael Comella (:mcomella) [not active on fennec/Bugzilla: contact me via IRC]
Modified: 2016-07-29 14:26 PDT (History)
16 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
affected
affected
affected
affected
affected
+


Attachments

Description User image Michael Comella (:mcomella) [not active on fennec/Bugzilla: contact me via IRC] 2012-07-02 12:26:50 PDT
1) Open Fennec.
2) Click the URL bar.
3) Enter "w3schools.com/html/tryit.asp?filename=tryhtml_intro".
4) Place your cursor in the blank line above "</body>" (note: you may need to zoom in to do this accurately).
5) Hold backspace.

Expected: All of the text in front of "</body>" will be deleted.
Actual: All of the text in the input box, including text behind the cursor (including "</body>") is deleted.

Steps 3-end can be completed on any page with a large amount of text in an input box (ex: Wikipedia edit page, typing a lot of text into Google search bar, etc.)

Text selection in the wrong direction seems to occur only when the cursor speeds up to delete faster.

Tested on Galaxy Nexus, Android 4.0.4, and Asus Transformer Prime TF201, Android 4.0.3.
Comment 1 User image Jason Smith [:jsmith] 2012-07-02 23:43:54 PDT
I can confirm this behavior as well when making apps on testmanifest.com. This is really annoying. Can we fix this?
Comment 2 User image Aaron Train [:aaronmt] 2012-07-06 11:43:35 PDT
I can reproduce too, and it's annoying.

All channel products are affected here.

Where I tested,

http://www.testmanifest.com, tap Edit, position your cursor anywhere in the large <textarea> and hold down on backspace and watch text delete in-front and behind the cursor. 

--
Samsung Galaxy Nexus (Android 4.1)
Nightly (07/06)
Comment 3 User image Aaron Train [:aaronmt] 2012-07-06 11:53:38 PDT
This is with the stock Android Input Method.
Comment 4 User image Chris Peterson [:cpeterson] 2012-07-18 15:19:38 PDT
I can repro this on my JB Galaxy Nexus. I suspect this is a race condition when the Gecko thread sends selection events to the UI/IME thread.
Comment 5 User image Demetrius Schwab 2012-08-06 13:40:47 PDT
I can reproduce this on my Nexus 7 and my Nexus S, both running Jelly Bean. It also will delete all the text but the last word typed in any input field if you hit backspace twice.
Comment 6 User image dawid.prokop.poland 2012-08-17 00:00:58 PDT
i have it to. in any text box. mosty with swiftkey but not only.and multi repeating words afer using backspace. prime asus
Comment 7 User image Aaron Train [:aaronmt] 2012-09-05 07:43:44 PDT
Still an annoying issue.

Can we get an update here?
Comment 8 User image Chris Peterson [:cpeterson] 2012-09-06 13:24:13 PDT
(In reply to Aaron Train [:aaronmt] from comment #7)
> Still an annoying issue.
> 
> Can we get an update here?

Aaron, can you still repro this bug in Nightly 2012-09-06? I wonder if my fix for bug 780543 will affect this bug.
Comment 9 User image Aaron Train [:aaronmt] 2012-09-06 13:41:50 PDT
Nightly 09/06 is still affected.
Comment 10 User image max vogel 2012-10-04 06:28:54 PDT
i am effected on Firefox beta android on my warp zte n860

this bug is awful
:(
Comment 11 User image Chris Peterson [:cpeterson] 2012-10-04 11:02:27 PDT
I can repro on Firefox 15, Beta 16, Aurora 17, and Nightly 18 with Galaxy Nexus stock keyboard, but not SwiftKey.
Comment 12 User image Marc Diethelm 2012-10-17 03:19:03 PDT
This is a critical bug and should be very high priority. In combination with not having undo functionality this leads to unrecoverable data loss in web apps.  Not joking here... I've lost actual data and can't get it back. It makes using FX Mobile to compose longer text (textarea) or edit existing text practically impossible. I had to type this comment in a writing tool and paste it into the text area (after starting over twice)...

Reproduced on Google Nexus 7 tablet, Google Nexus S phone.

Calling this bug 'annoying' is the understatement of the year.  ಠ_ಠ
Comment 13 User image Gian-Carlo Pascutto [:gcp] 2012-10-17 09:24:26 PDT
Jim told me he already looked at this and is willing to take it.
Comment 14 User image Jim Chen [:jchen] [:darchons] 2012-10-17 14:02:21 PDT
I was hoping the fix to Bug 792928 would fix this as well, but it didn't :(

Instead of trying to find a bandaid for this bug, the better approach is probably to focus effort on Bug 769520, which would fix this bug as well.
Comment 15 User image Marc Diethelm 2012-10-18 02:18:23 PDT
Don't know if this has any relevance to fixing this bug, but using a different keyboard (eg. Swiftkey) works around this issue.
Comment 16 User image Aaron Train [:aaronmt] 2012-10-28 07:24:34 PDT
*** Bug 806188 has been marked as a duplicate of this bug. ***
Comment 17 User image Jim Chen [:jchen] [:darchons] 2012-11-05 11:21:57 PST
No longer reproducible after Bug 805162.
Comment 18 User image Nexan 2012-11-21 13:17:48 PST
On my Device a Nexus 7 with Android 4.2 this Bug is still reproducible with Firefox 17. It's really annoying.
Comment 19 User image Nexan 2012-11-24 06:27:59 PST
No more work on this bug? So users of Nexus Devices have to switch the keyboard or use Google Chrome if they want to use text input on websites?
Comment 20 User image Aaron Train [:aaronmt] 2012-11-25 07:55:05 PST
(In reply to Nexan from comment #19)
> No more work on this bug? So users of Nexus Devices have to switch the
> keyboard or use Google Chrome if they want to use text input on websites?

The target milestone for a fix in bug 805162 is in Firefox 19; although the decision to uplift may come sooner. In-fact, I'd vote for it.
Comment 21 User image Kevin Brosnan [:kbrosnan] 2012-11-26 14:36:43 PST
It will be part of Firefox 19. Release management already have talked with the parties involved and agree that the risk of issues due to rushing this fix out the door is too high.
Comment 22 User image Nexan 2012-11-26 15:28:50 PST
Ok, but it's a little bit confusing that this bug is marked as fixed in official changelog for Firefox 17: http://www.mozilla.org/en-US/mobile/17.0/releasenotes/
Comment 23 User image Gian-Carlo Pascutto [:gcp] 2012-11-26 23:40:18 PST
You're right, that appears to be a mistake in the release notes. Reported to release management.

Note You need to log in before you can comment on or make changes to this bug.