Closed Bug 770291 Opened 13 years ago Closed 12 years ago

Holding backspace may delete text both in front of and behind the cursor

Categories

(Firefox for Android Graveyard :: Keyboards and IME, defect, P2)

Product:
Firefox for Android Graveyard
Component:
Keyboards and IME
Platform:
ARM
Android
Type:
defect

Tracking

(firefox14 affected, firefox15 affected, firefox16 affected, firefox17 affected, firefox18 affected, fennec+)

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox14 --- affected
firefox15 --- affected
firefox16 --- affected
firefox17 --- affected
firefox18 --- affected
fennec + ---

People

(Reporter: mcomella, Assigned: jchen)

References

(
URL
)

Details

(Keywords: dataloss)

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.
Summary: [Fennec] 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
I can confirm this behavior as well when making apps on testmanifest.com. This is really annoying. Can we fix this?
tracking-fennec: --- → ?
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)
status-firefox14: --- → affected
status-firefox15: --- → affected
status-firefox16: --- → affected
Version: Firefox 16 → Firefox 14
This is with the stock Android Input Method.
tracking-fennec: ? → +
Assignee: nobody → cpeterson
Status: NEW → ASSIGNED
Priority: -- → P2
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.
URL: http://w3schools.com/html/tryit.asp?f...
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?
status-firefox18: --- → affected
(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.
Keywords: qawanted
Nightly 09/06 is still affected.
Keywords: qawanted
i am effected on Firefox beta android on my warp zte n860 this bug is awful :(
Version: Firefox 14 → Trunk
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. ಠ_ಠ
Assignee: cpeterson → gpascutto
Jim told me he already looked at this and is willing to take it.
Assignee: gpascutto → nchen
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.
Depends on: 769520
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.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
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.
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.