Perhaps, after fixing bug 1529884, we could fix this easier than current design. I'll try to fix this in 69.

Not actually working on, but I'd like to fix this later (currently, "beforeinput" event support is more important).

Hello,

I am just dropping by to say that I have referenced this bug report in a Stack Overflow answer.

https://stackoverflow.com/a/58437149/3961271

Probably, I should work on this when I have much time at implementing "beforeinput" event, e.g., when I wait review.

FYI: I've already added WPT for this https://searchfox.org/mozilla-central/source/testing/web-platform/tests/editing/other/exec-command-with-text-editor.tentative.html
And mostly, I have idea where needs to be changed for execCommand. However, I'm still not sure about other related API like queryCommandEnabled etc, but perhaps, not so difficult.

@masayuki

I don't think any changes are necessary for queryCommandEnabled, since all the command-related functions are children of the document object. In Firefox (tested on 69 and 70), document.queryCommandSupported('insertText') (and same for "paste") already return true, indicating that the commands are supported (they just don't work if the cursor is in a textarea or input element... which I would argue is the most common reason to use these commands).

To me it is crazy that HTML5 doesn't simply have an attribute, for the textarea element, that enables your ability to type tabs into textareas.

Thankfully, in Chrome you can accomplish this sensibly using document.execCommand:
https://stackoverflow.com/a/52918135/217867

However, in Firefox, I'm having to write code that "changes the whole value of the textarea" in order to simply insert a tab, and this technique breaks undo-functionality. Imagine textareas with huge amounts of text in them; its crazy to have to change the whole textareaElement.value just to insert a '\t'.

Masayuki, I too think it is a bit strange that the .execCommand method is just on the document object. You'd think this would be a prototype method on "all html elements that can receive inputted text".

However, I'll say this, given the way it is, you should simply look at which element has focus, at the time that document.execCommand is called, and take note of the caret position within that focused element, and then write the text at that caret location. This seems to be how Chromium is accomplishing this.

I concur, this is really irritating if you want to insert text into a textarea and preserve the ability to undo/redo. document.execCommand seems to be the only way to do that.

I agree that this is an important issue. As far as I can tell, it's currently impossible to implement a decent (<textarea>-based) text editor that works in Firefox. One must either make editor controls unintuitive and annoying by having them never replace selected text (so the user can't irrevocably delete text by accidentally hitting the wrong control), or let them be mines waiting for the user to step on them. Neither option is good. And either way, not being able to undo/redo is of course very annoying for the user.

Resetting assignee which I don't work on in this several months.

Editor command should be handled in same command table between ExecCommand
and the other related methods. However, currently, only ExecCommand does
optimized things. For using same logic in the other methods, the code should
be in an independent stack class.

Depends on D108566

This will guarantee that when <input> or <textarea> is in contenteditable,
execCommand and the other related methods work with same command class
instance and same command context (in this case, it's editor instance).

Depends on D108567

For making execCommand and related methods with <input> and <textarea>
even if they are in contenteditable and focused, command should be handled
in active editor (focused editor if in foreground window and tab).

However, some commands should be handled by HTMLEditor even if an TextEditor
has focus. Therefore, this patch adds new enum class which have 3 state into
InternalCommandData and makes AutoEditorCommandTarget consider it with the
enum class.

Note that the new failures about contentReadOnly command will be fixed by
a following patch.

Depends on D108568

Currently, Document checks it only with whether the document is editable
or not. Only with this check, execCommand and the other related methods
work only when there is contenteditable.

Therefore, this patch makes it to check whether the target is editable or not
with target editor.

Depends on D108569

Although this command is supported only by Gecko, we shouldn't stop supporting
this unless we know the usage in the wild. Therefore, this patch adds the
handling code for TextEditor too.

Depends on D108570

Those command handlers just check whether the given editor is an HTMLEditor
or not. Therefore, we should make them check whether the given editor is
a single line editor or not instead.

Depends on D108571

Backed out for causing build bustages.

Backout link: https://hg.mozilla.org/integration/autoland/rev/b2032cc5823b489b8b5103ae6c5fb84f85c6f630

Push where the failure started: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=KyZ4VnsDT2KNwPSuSjVUwQ.0&revision=4d707f323366dd5d4db4d1ac07526e01f107f21a&searchStr=linux%2Cx64%2Cdebug%2Cbuild-linux64-base-toolchains%2Fdebug%2Cbb

Failure log: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=KyZ4VnsDT2KNwPSuSjVUwQ.0&revision=4d707f323366dd5d4db4d1ac07526e01f107f21a&searchStr=linux%2Cx64%2Cdebug%2Cbuild-linux64-base-toolchains%2Fdebug%2Cbb

The behavior will be:

• When <input> or <textarea> has focus, most commands of execCommand, etc are handled by it.
• When they are disabled, they just do nothing, and also the document's editor does nothing too.
• The commands which set document state like default paragraph separator, using CSS or HTML inline-style elements, they are always handled by the document's HTML editor, even when <input> or <textarea> has focus.
• The commands which set inline or block style around selection, they do nothing when <input> or <textarea> has focus.

Please note Bug 1695659 which may have an affect on this bug as well (execCommand on page with iframes).

(In reply to erosman from comment #59)

Please note Bug 1695659 which may have an affect on this bug as well (execCommand on page with iframes).

clipboard commands are handled only with focused descendant if an <iframe> has focus, and won't be go back to parent document from a child document if the execCommand is called in a child document.

https://hg.mozilla.org/mozilla-central/rev/2ebe50bc5498
https://hg.mozilla.org/mozilla-central/rev/b6bd98c80b7b
https://hg.mozilla.org/mozilla-central/rev/c1739e11849e
https://hg.mozilla.org/mozilla-central/rev/4580967d47ff
https://hg.mozilla.org/mozilla-central/rev/40020a5f44e1
https://hg.mozilla.org/mozilla-central/rev/c8b24f26ba71
https://hg.mozilla.org/mozilla-central/rev/afd35aefdf51

See compatibility result:
https://wpt.fyi/results/editing/other/exec-command-with-text-editor.tentative.html?label=experimental&label=master&aligned

Hi :masayuki!

I'm currently trying to work out how to document this change on MDN. Does the following description and requirements sound accurate, or is it not that simple?

"
Release note:

From Firefox 89 onwards, the content of <input> and <textarea> elements that have been put into designMode or had contentEditable set on them can now be manipulated using Document.execCommand() commands, preserving edit history and providing parity with other browsers.

Add browser compat data to make this change clear on:

• https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand
• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input
• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea
  "

Do we need to say exactly which execCommand() commands were affected, and if so, do you have a definitive list?

Thanks.

Thank you for updating the doucments!

From Firefox 89 onwards, the content of <input> and <textarea> elements that have been put into designMode or had contentEditable set on them can now be manipulated using Document.execCommand() commands

Now, they don't require designMode nor contenteditable. They were required 88 and earlier ("have been/had"'s nuance is unclear to me in this case).

Do we need to say exactly which execCommand() commands were affected, and if so, do you have a definitive list?

I don't think it's required because I don't check the other browsers' behavior so deeply. If you want to do it, you can check our source code:
https://searchfox.org/mozilla-central/rev/1df3b4b4d27d413675fb66f375230cb25d636450/dom/base/Document.cpp#4414,4420,4422,4428,4430,4436,4438,4444,4446,4452,4454,4460,4462,4468,4470,4476,4478,4484,4486,4492,4494,4500,4502,4508,4510,4516,4518,4524,4526,4531,4533,4539,4541,4547,4549,4555,4557,4563,4565,4571,4573,4579,4581,4587,4589,4595,4597,4603,4605,4611,4613,4619,4621,4627-4630,4632,4638,4640,4646-4649,4651,4657,4659,4665,4667,4673,4675,4681,4683,4689,4691,4697,4699,4705,4707,4713,4715,4721,4723,4729,4731,4737,4739,4745,4747,4753,4755,4761,4763,4769,4771,4777,4779,4785,4787,4793,4795,4801,4803,4809,4811,4817

• CommandOnTextEditor::Enabled means the command is handled (and consumed) by <input> or <textarea> if and only if one has focus.
• CommandOnTextEditor::Disabled means the command is not handled and consumed by <input> or <textarea> if and only if one has focus (i.e., even if one is in contenteditable, it's not handled by the HTML editor too)
• CommandOnTextEditor::FallThrough means the command is handled by contenteditable even if <input> or <textarea> has focus. In this case, the focused one does not need to be in contenteditable. It affects to HTMLEditor instance which manage all contenteditables in the document.

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #66)

Thank you for updating the doucments!

From Firefox 89 onwards, the content of <input> and <textarea> elements that have been put into designMode or had contentEditable set on them can now be manipulated using Document.execCommand() commands

Now, they don't require designMode nor contenteditable. They were required 88 and earlier ("have been/had"'s nuance is unclear to me in this case).

Ah, great, thanks :masayuki!

I understand this better now, and after doing a bit of testing. I'm going to update the rel note text to:

"From Firefox 89 onwards, the content of <input> and <textarea> elements can now be manipulated using Document.execCommand() commands by default, preserving edit history and providing parity with other browsers, without contentEditable or any lengthy workarounds required ({{bug(1220696)}})."

I'll set this to dev-doc-complete now, but please speak up if you think the MDN notes need changing. Thanks!

See https://github.com/mdn/content/issues/4311 for the full details of what was done for the docs.

Thanks, that looks good to me!