document.execCommand("insertText") on textarea tags

Talk about code development, features, specific bugs, enhancements, patches, and similar things.
Forum rules
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific bugs, git, the repositories, etc.

This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Please post issues with specific websites, extensions, etc. in the relevant boards for those topics.

Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
User avatar
Maiii
New to the forum
New to the forum
Posts: 2
Joined: 2022-09-24, 09:09

document.execCommand("insertText") on textarea tags

Unread post by Maiii » 2022-09-24, 09:19

Hello,

It seems that document.execCommand("insertText") currently only works on contenteditable elements in palemoon. Every other browser I know of (including newer versions of firefox) also supports this on textarea tags, and allows inserting text into textareas while preserving the undo stack for that textarea. In palemoon changing the value of the textarea also preserves the undo stack (unlike other browsers), so this is not an insurmountable problem, but it does mean that it requires a special case. If it's not too difficult to change, it would be nice if palemoon could also support document.execCommand("insertText") for this context. I understand that this is a deprecated feature, but no real alternative exists for it.

For firefox, this behaviour seems to have changed in firefox 89, previously it matched palemoon: https://bugzilla.mozilla.org/show_bug.cgi?id=1220696

In the long run this will probably also cause compatibility issues with websites, since the behaviour now matches in safari, chrome and firefox.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 33027
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: document.execCommand("insertText") on textarea tags

Unread post by Moonchild » 2022-09-24, 09:42

I'm sorry but historically, interaction with form inputs has always been through setting .value - execCommand is a much more complex mechanism that our form controls simply don't support because it's not part of the same code context. For plaintext pasting etc. it's also not necessary; and I don't know how well that would interact with form history, undo (which does work fine for .value), etc. -- it seems to be another case of Mozilla doing something illogical only because Chrome does it, if I look at the linked bug.

I'm aware that if websites are exclusively using execCommand in the future that programmatic insertion of text in input controls might no longer work, but there really is no reason why we'd want to use a deprecated and unnecessarily complex mechanism for this that isn't even compatible with the type of element. In addition, websites should not migrate towards officially deprecated methods and this can be squarely laid at the feet of webmasters in that case.
"The best revenge is to not be like the person who wronged you." -- Marcus Aurelius
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb

User avatar
Maiii
New to the forum
New to the forum
Posts: 2
Joined: 2022-09-24, 09:09

Re: document.execCommand("insertText") on textarea tags

Unread post by Maiii » 2022-09-24, 09:54

The logic I saw in it is that it makes the mechanism for modifying a text field value while preserving the undo stack explicit and different from overwriting the value with something in a way that should not be undoable. No idea if that's mozillas official reasoning, but I digress. But fair enough if it's difficult to implement, it's not the end of the world for me to check if the insertText succeeded, and to fall back to modifying the value directly. Thank you for the quick response in any case.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 33027
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: document.execCommand("insertText") on textarea tags

Unread post by Moonchild » 2022-09-24, 10:16

Yeah, it's one of those things where one vendor decided to push for one particular alternate implementation and refusing to use already-established methods. The thing is that the web has a standards history, and specific approaches inherent to it, and you can't just treat it like something proprietary that you can just change because someone in a board room decided that change is beneficial. The same thing happened for example with the infamous <button> problem: HTML4 specifies explicitly that they contain only phrasing content and events land on the button element, yet Chrome pushed the implementation of it as a generic container.
it makes the mechanism for modifying a text field value while preserving the undo stack explicit
Reading more into the bug this topic relates to, it seems the only reason for the change from .value to execCommand was to "repair" the undo because it was explicitly removed prior only to chase benchmark scores :crazy: -- But we've seen that before plenty of times too: first break something, then reintroduce a completely different way of doing the exact same thing as something "new". It's one of those things that really grinds my gears. There was no issue except with a limitation in Chrome that gave better benchmark scores; Mozilla followed the bahvior to improve benchmark scores, breaking undo; then following Chrome once more by implementing the undo mechanism again in a different way that is actually deprecated functionality (but won't be removed because Chrome doesn't). We have other APIs for this too, like the Clipboard API, that also interacts favourably with normal text input in a standard way.

Anyway, sorry about the small rant.
"The best revenge is to not be like the person who wronged you." -- Marcus Aurelius
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb

Post Reply