New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

INPUT/TEXTAREA should support subset of execCommand #160

Open
yosinch opened this Issue Jan 18, 2017 · 18 comments

Comments

Projects
None yet
8 participants
@yosinch

yosinch commented Jan 18, 2017

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

This comment has been minimized.

Contributor

johanneswilm commented Jan 18, 2017

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

This comment has been minimized.

Yaffle commented May 26, 2017

Firefox 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

This comment has been minimized.

@hfhchan

This comment has been minimized.

hfhchan commented Sep 14, 2017

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

This comment has been minimized.

Eccenux commented Oct 9, 2017

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

This comment has been minimized.

eranroz commented Oct 20, 2017

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

@makotokato

This comment has been minimized.

makotokato commented Jun 8, 2018

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

This comment has been minimized.

Contributor

johanneswilm commented Jun 8, 2018

@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

This comment has been minimized.

Contributor

johanneswilm commented Jun 8, 2018

@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

This comment has been minimized.

Contributor

johanneswilm commented Jun 8, 2018

@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

This comment has been minimized.

masayuki-nakano commented Jun 8, 2018

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

This comment has been minimized.

Contributor

johanneswilm commented Jun 8, 2018

@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

This comment has been minimized.

eranroz commented Jun 8, 2018

@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

This comment has been minimized.

Contributor

johanneswilm commented Jun 8, 2018

@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

This comment has been minimized.

masayuki-nakano commented Jun 9, 2018

@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

This comment has been minimized.

Contributor

johanneswilm commented Jun 10, 2018

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

This comment has been minimized.

masayuki-nakano commented Jun 10, 2018

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

This comment has been minimized.

Contributor

johanneswilm commented Jun 10, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment