`Document.execCommand`, `Document.queryCommandValue`, `Document.queryCommandState`, `Document.queryCommandEnabled`, `Document.queryCommandSupported`, `Document.queryCommandIndeterm` behavior when an EditContext editing host has focus

[masayuki-nakano]

I think Document.execCommand should return false and does nothing. Document.queryCommandEnabled and Document.queryCommandSupported should return false. Document.queryCommandState should return false. Document.queryCommandValue should return empty string. And Document.queryCommandIndeterm should return false even though may be opposite from the name, but I think browsers returns false if the command is not available.

[masayuki-nakano]

I think that this should be defined in "1.2.3 Differences for an EditContext editing host". https://w3c.github.io/edit-context/#edit-context-differences

[johanneswilm]

It is possible that in five years time, contenteditable usage will have been replaced entirely by edit context and new developers will not know what execCommand even is. Then it would be the best if everything related to execCommand is in the execCommand spec and not everywhere else.

In order to not litter execCommand in every new spec, would it be possible to put this into the execCommand spec itself instead?

CC: @zcorpan

[dandclark]

I agree that completely disabling execCommand and the related functions for EditContext is probably best.

[dandclark]

I reached out to the Google Docs team, who are using EditContext in an Origin Trial, and they told me they still use execCommand to trigger copy/paste. They're looking into moving to the clipboard API, but until that happens removing execCommand support would be a blocker for them adopting EditContext. They're also worried that some browser extensions rely on insertText to inject content, and that this would break those extensions as well.

Since it seems like this might be a blocker to adopting EditContext, I wonder if it would make sense to support some small subset of commands like:

• "cut"
• "copy"
• "paste"
• "insertText"

It seems like supporting those would be straightforward to implement for EditContext and could make it easier for developers to migrate to EditContext.

[johanneswilm]

Exchanging execCommand in these cases with their clipboard API equivalents is changing a one-liner. The main problem with the clipboard API and why execCommand is still used is that in Firefox Clipboard.write is still behind a flag and has been there for 5 years now [1]. What is the holdup there, @masayuki-nakano? Any chance the flag will be removed any time soon?

I think we can be even more restricted than that:

• Cut - does the same as copy + deletes text. In EditContext it is the JavaScript app that needs to make dom modifications anyway, so cut will do the same as copy. Therefore no need to have cut.

• Paste - document.execCommand("paste") is disabled by default. So maybe not needed? In Google Docs it seems to be enabled by means of a browser extension that one needs to install to make pasting work.

• InsertText - doesn't seem to interact with the clipboard and only makes DOM changes. So therefore it is not needed for EditContext

So essentially we would only need to support document.execCommand("copy") - which is an execcommand that works without an editing host.

So essentially, I would say we should make no provisions for supporting any execCommands on EditContext. Even if they somehow manage to get document.execCommand("paste") command enabled somehow in Google Docs, they should be able to just do as now and paste into a hidden contenteditable and then cleanup the result until Firefox removes flags.

[1] https://caniuse.com/?search=Clipboard.write

[masayuki-nakano]

The main problem with the clipboard API and why execCommand is still used is that in Firefox Clipboard.write is still behind a flag and has been there for 5 years now [1]. What is the holdup there, @masayuki-nakano? Any chance the flag will be removed any time soon?

I'm not work around there. @EdgarChen , do we have a schedule to ship it?

[masayuki-nakano]

The execComnand usage is indeed interesting. WebExtentions do not have API to emulate user input. So, it might be better that EditContext has some API for them. Then, it could be useful for testing the web apps.

[dandclark]

I think Document.execCommand should return false and does nothing. Document.queryCommandEnabled and Document.queryCommandSupported should return false. Document.queryCommandState should return false. Document.queryCommandValue should return empty string. And Document.queryCommandIndeterm should return false even though may be opposite from the name, but I think browsers returns false if the command is not available.

I think we could say that the exception to this should be for command types that aren't dependent on where user selection is in the document. For example since execCommand("copy") (note:my original comment said execCommand("cut") here but it should be execCommand("copy")) works anywhere in the document, including in non-editable text, it would be strange to restrict it only in EditContext.

For queryCommandSupported, at least in Chrome this works at the level of the page and is never dependent on user selection. So I don't think it makes sense to disable it when focus is in an EditContext, since there is currently no difference if it's called in an editable region vs non-editable region.

On the other hand, queryCommandEnabled is dependent the selection position for some command types so we can disable it for EditContext for those command types.

[dandclark]

One other caveat I noticed here is that at least in Chromium, execCommand("cut") and execCommand("paste") return true even if they don't do anything because selection is not in an editable region. So I think for consistency it should be the same for EditContext for these two: both return true but don't do anything if selection is in EditContext, just like if selection was on non-editable text.

[dandclark]

Notes from 2023-11-09 call:

[17:55] johanneswilm: what connection should there be between execCommand and EC? [17:55] q+ [17:56] dandclark: agree with johanneswilm, copy needed. agree with masayuki, we don't generally want to support this [17:57] q+ [17:57] dandclark: simplest solution: commands that are available when focused in non-EC should be available in EC [17:58] edgar: we are working on shipping clipboard API (?) [17:58] johanneswilm: resolve on dandclark's comment above