INPUT/TEXTAREA should support subset of execCommand

[yosinch]

It is useful to support some execCommand, e.g. cut, paste, insertText, undo/redo, in INPUT/TEXTAREA to utilize undo facility with modification.

As of January 2017, Blink and WebKit support execCommand in INPUT/TEXTAREA[1]

[1] http://crbug.com/558919 execCommand should not work on INPUT/TEXTAREA

[johanneswilm]

As for the need for UNDO: This seems at least in part to be the issue of global undo again. This isn't used at all in any richtext editor, but it would seem that this could potentially be useful in a form with input/textarea.

The usage statistics you have found (less than 0.0061% of sites) seems to indicate that this is not the case currently.

So instead of trying to increase the number of users on this, could we not wait until there is a replacement for execCommand for clipboard events and then use that instead?

Do we have any idea what those 0.0061% of sites it for? Because if it's just part of some trick to get the plaintext version of the paste for a richtext editor, it seems somewhat useless.

[Yaffle]

Firefox (before version XX) supports UNDO when you set the textarea.value or when you do textarea.setRangeText().
IE supports document.execCommand('ms-beginUndoUnit'), document.execCommand('ms-endUndoUnit') on <textarea>

[makotokato]

Gecko's bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1220696

[hfhchan]

Gecko no longer supports undo on textarea.value.

Manually splicing textarea values with some substring indexOf logic is rather complex when the desired task is just to insert a few characters at the cursor, or replace the whole line.

[Eccenux]

The usage statistics might change dramatically when developers figure out why the undo function is not working and how to fix it. In other words -- I think deciding only on current usage stats would not be a good thing.

I see no security reason of why would copy/paste be unavailable for textarea when it is already available for elements with contenteditable attribute.

BTW Github editor is suffering from the undo problem too. And I'm guessing it is using pasting trick as it works in Chrome and not in Firefox. Just try using e.g. the bold button in the editor.

[eranroz]

Would be useful also for Mediawiki/wikipedia. see: https://phabricator.wikimedia.org/T33780

[makotokato]

Edge seems to support execCommand... So Gecko is only browser that doesn't support execCommand('insertText') for form w/o contentedtiable. (copy/cut/paste will be worked)

@johanneswilm, This behaviour don't have document and web-platform-test for execCommand support for form. If it is clear for document or agreement of all vendors, I will consider to implement it for compatibility. Who is good person at Microsoft?

Cc: @masayuki-nakano

[johanneswilm]

@eranroz You are aware that the browser-provided undo is the same for all text input elements on the same page, right? So if someone:

1. Writes something in the editor
2. Clicks into another input element so that the cursor moves there.
3. Hits the key combination for undo

The result will be that the editor that caret was in at step 1 will get the undo because that's where the last edit was. This is the way it works in all browsers [Edit: Chrome and at least previously also other browsers, whereas Firefox keeps contenteditable and input/textarea apart] and it breaks all richtext text editor applications I could find, including Mediawiki Visual Editor [1].

[1] #150

[johanneswilm]

@Eccenux The way undo works from the browser's perspective and from the perspective of web apps is fundamentally different. All text editing apps I could find approach it with an idea that they have their own undo stack. Browser's don't provide that. So execCommand doesn't give them want they want anyway.

[johanneswilm]

@makotokato possibly it may make sense to implement so that the bugs on Firefox align more with bugs on other browsers. But in general this is not a good idea as long as there is only one global undo stack, because it breaks any richtext editor on the same page. Maybe we need to talk again about being able to at least opt out of the global undo stack for certain elements. Then that should be much less of a problem. Microsoft should be following this thread. If they don't, I'll try to get someone to respond or contact you.

[masayuki-nakano]

Gecko creates undo stack per <input>/<textarea> element and only one stack for contenteditable/designMode. execCommand is available only with a method of document. So, if Gecko starts to support execCommand in <input>/<textarea>, Gecko will record the edit actions into each <input>/<textarea>.

[johanneswilm]

@masayuki-nakano Ok, perfect. Good that input/textarea then don't interfere with contenteditable elements. They do interfere in other browsers (I tested Chrome today), and I'm not sure all JS developers are aware of this because it doesn't seem like something one should need to test for. In that case I am not against making these execCommand actions available on Firefox as we are not creating any new issues.

If I understand you correct, you still have a common undo stack for all contenteditable elements on the same page? That is also not very practical, but the problems created are smaller, in that its less common to have more than one contenteditable element at the same time.

[eranroz]

@johanneswilm : I'm aware to this behavior. The main issue in question is not a user editing but rather a script editing e.g

1. User clicks on some button to manipulate text/replace it etc (example: $('textarea').val('new content') )
2. it is not possible to undo this change

[johanneswilm]

@eranroz Right, but the question behind this is: do we want the browser to provide this global undo stack or not. Currently it's hurting all the richtext editors, including the Wikimedia one and those created by browser makers. Browser priorities are generally not in favor of text editing because they have so many other things to look at. I see your bug report is from 2011. In a choice between either:

A) getting more of this global undo stack added to the browsers, and trying to be smart and somehow guess what happens with script-added content whereby another 15 bugs are added and the browser makers will wait another 5-7 years before browser makers again have the resources to look at editing again, and

B) getting an option to opt out of the global undo stack for an individual elements and so that you can then program your own undo system without interference from the browser,

I think B will be the clear choice for most JS editors. Every richtext editor has programmed their own undo system anyway.

That being said, if what Firefox will add to input and textarea is completely isolated within each element, then I don't think it's problematic for them to add it.

[masayuki-nakano]

@johanneswilm

If I understand you correct, you still have a common undo stack for all contenteditable elements on the same page?

Exactly.

That is also not very practical, but the problems created are smaller, in that its less common to have more than one contenteditable element at the same time.

I have no idea how to manage undo stack separately for each contenteditable element. If there is no contenteditable="false", it could be though...

[johanneswilm]

I have no idea how to manage undo stack separately for each contenteditable element.

Just being able to entirely disable the undo stack for a contenteditable element would help, because then one doesn't have to worry about undo events coming in while the selection is in another element on the page. In that case it would be important that browser native buttons for undo and redo can be enabled/disabled by means of JavaScript.

If there is no contenteditable="false", it could be though...

I don't think I understood this sentence.

[masayuki-nakano]

I have no idea how to manage undo stack separately for each contenteditable element.

Just being able to entirely disable the undo stack for a contenteditable element would help, because then one doesn't have to worry about undo events coming in while the selection is in another element on the page. In that case it would be important that browser native buttons for undo and redo can be enabled/disabled by means of JavaScript.

Sounds like there should be a command to disable/enable undo of HTML editors?

If there is no contenteditable="false", it could be though...

I don't think I understood this sentence.

For example,

<div contenteditable>
  <p><br></p>
  <div contenteditable="false">
    <p>Something: <span contenteditable>value</span></p>
  </div>
</div>

<span contentediable> can be modified when both: [div contenteditable] has focus and [span contenteditable] has focus. So, browser cannot associate each edit operation to which editing host's undo stack. Even if it always associated into the innermost editing host, that causes users cannot undoing changes in <span contenteditable> when they tries to undo if <div contentediable> has focus.

[johanneswilm]

Sounds like there should be a command to disable/enable undo of HTML editors?

Well, we want to get away from having to execute commands to be able to use editors the way we have had to do a while with Firefox. We have a resolution to create a contenteditable-disable-attribute [1]. I think this may be the time to start working on a first list. In your example, it would be something like this:

<div contenteditable contenteditable-disabled="history">
  <p><br></p>
  <div contenteditable="false">
    <p>Something: <span contenteditable contenteditable-disabled="history">value</span></p>
  </div>
</div>

And this should make sure that actions in either of these are not added to the global undo stack. I will try to present a first list over the course of the next week.

[1] https://www.w3.org/2017/11/07-editing-minutes.html#resolution01

[foudadev]

I Do many of tries to solve this problem I need to use Textarea in-text editor to make many options like execCommand supported what should I do ?!

[Yaffle]

@yehiafouda , you could use contenteditable=true for now, to make it plaintext-only you could listen for "beforeinput" and prevent/handle based on the event type, which is not future-compatible, but at least something...

[Eccenux]

Just to let you know. Firefox just implemented this (in FF 89). So there is currently no browser that doesn't support this... Well, except IE, but IE is not developed any more.
https://bugzilla.mozilla.org/show_bug.cgi?id=1220696

[Yaffle]

@Eccenux , very good progress!
will it uses "individual undo stack for the textarea element"? or "global undo stack"?

[masayuki-nakano]

will it uses "individual undo stack for the textarea element"?

Yes, it'll do. Gecko just redirect command to focused editor even if it's readonly or disabled.
https://wpt.fyi/results/editing/other/exec-command-with-text-editor.tentative.html?label=experimental&label=master&aligned

Perhaps, Gecko stops supporting Gecko specific command if they are not used actually in the wild.