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

RESOLVED WORKSFORME

Status

()

Firefox for Android
Keyboards and IME
P2
normal
RESOLVED WORKSFORME
5 years ago
11 months ago

People

(Reporter: mcomella, Assigned: jchen)

Tracking

({dataloss})

Trunk
ARM
Android
dataloss
Points:
---

Firefox Tracking Flags

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

Details

(URL)

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

Updated

5 years ago
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.

Updated

5 years ago
status-firefox17: --- → affected

Comment 5

5 years ago
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

5 years ago
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

Comment 10

5 years ago
i am effected on Firefox beta android on my warp zte n860

this bug is awful
:(

Updated

5 years ago
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.

Comment 12

5 years ago
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.  ಠ_ಠ
Keywords: dataloss
Assignee: cpeterson → gpascutto
Jim told me he already looked at this and is willing to take it.
Assignee: gpascutto → nchen
(Assignee)

Comment 14

5 years ago
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

Comment 15

5 years ago
Don't know if this has any relevance to fixing this bug, but using a different keyboard (eg. Swiftkey) works around this issue.

Updated

5 years ago
Duplicate of this bug: 806188
(Assignee)

Comment 17

5 years ago
No longer reproducible after Bug 805162.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME

Comment 18

5 years ago
On my Device a Nexus 7 with Android 4.2 this Bug is still reproducible with Firefox 17. It's really annoying.

Comment 19

5 years ago
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.

Comment 22

5 years ago
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.
You need to log in before you can comment on or make changes to this bug.