1112276 - "cut" should work for contentEditable selections

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Text Selection, defect, P5)

Description

[Mike Taylor [:miketaylr]]

See Bug 783846, which covered paste not working. Cut should also be possible to get working.

Comment 1

[Mark Capella [:capella]]

I noticed you can't use element.value to cut here
(contentEditable HTMLElements use nsHTMLEditor vs nsIEditor (iirc) ...)

http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/SelectionHandler.js?rev=7a58fbd76acd&mark=673-673#664

Switching to something along the lines of:
Selectionhandler.getSelection().deleteFromDocument();

Should work for editables (HTMLInputElement, HTMLTextAreaElement) and contentEditables.

Comment 2

[Mike Taylor [:miketaylr]]

Oh sweet. My first attempt was substring'ing textContent but I wasn't sure how that would behave across nodes, etc.

Comment 3

[Mark Capella [:capella]]

exactly! In one edge case, if the user has (apparently) selected all content by dragging the handle to the right edge of an editable, the focusNode can become the next node with an offset of 0 (-ish - there's more to that story where it can actually wind up as the parent node with an offset of 1).

If the container is an <input>, the #text node is an anonymous node of an anonymous parent div. For <textareas> there can be a terminating anonymous <br> inside the editable, and other weird-ness 

So that rats nest is best avoided :-D

Comment 4

[Mike Taylor [:miketaylr]]

Attachment: 0001-Bug-1112276-Enable-cut-for-contentEditable-selection.patch

Here's a patch that has cut working, but I ran into some problems with the Robocop tests failing (for reasons I don't understand yet). I probably won't have time to get back into this for a few weeks if some one wants to take over.

Comment 5

[Mike Taylor [:miketaylr]]

To be more clear, the tests that were failing were the tests I'm trying to write for "cut". Everything else passed.

Comment 6

[Mark Capella [:capella]]

Pruning some old bugs (part 2) either:
   ) obviated by new Core/Layout AccessibleCaret implementation in m-c and stable, targeted for 47.
   ) Or no longer being observable.

If you still see what you consider incorrect behaviour with the new version, please file a new bug targeted there, and attach a test-case or example link to help things :-)


Specific Note here: Works now, using test page: [0], and contenteditable fields on bottom (TAP ME TAP ME) etc.

 [0] https://www.dropbox.com/s/j5jcon30y8vda3u/test_bug988143.html?dl=0