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.
I can confirm this behavior as well when making apps on testmanifest.com. This is really annoying. Can we fix this?
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)
This is with the stock Android Input Method.
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.
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.
i have it to. in any text box. mosty with swiftkey but not only.and multi repeating words afer using backspace. prime asus
Still an annoying issue. Can we get an update here?
(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.
Nightly 09/06 is still affected.
i am effected on Firefox beta android on my warp zte n860 this bug is awful :(
I can repro on Firefox 15, Beta 16, Aurora 17, and Nightly 18 with Galaxy Nexus stock keyboard, but not SwiftKey.
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. ಠ_ಠ
Jim told me he already looked at this and is willing to take it.
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.
Don't know if this has any relevance to fixing this bug, but using a different keyboard (eg. Swiftkey) works around this issue.
No longer reproducible after Bug 805162.
On my Device a Nexus 7 with Android 4.2 this Bug is still reproducible with Firefox 17. It's really annoying.
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?
(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.
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.
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/
You're right, that appears to be a mistake in the release notes. Reported to release management.