What did you do? ================ <!doctype html> <html> <head> <title>Test</title> </head> <body> <textarea designMode="on" id="textarea"></textarea> <a href="#" onclick="document.getElementById('textarea').focus(); document.execCommand('insertText', false, 'Text'); return false;">Insert text</a> <a href="#" onclick="document.getElementById('textarea').value = ''; return false;">Reset</a> </body> </html> What happened? ============== Insert text works properly as long you don't change it's value What should have happened? ========================== Should also work after editing text Is there anything else we should know? ======================================
Sounds like you're trying to report a bug in Firefox.
Component: General → General
Product: Mozilla Developer Network → Firefox
You're right Luke Crouch, I missed that one, sorry for any inconvenience!
Component: General → Editor
Product: Firefox → Core
Summary: textarea execcommand not working properly → textarea execcommand insertText not working properly
Here is a jsFiddle that I created that illustrates the bug, https://jsfiddle.net/dvo5pnvy/3/. In chrome, safari, and edge, when pasting into the input text box, the string "This should be pasted." is pasted in, no matter what is in your clipboard. In firefox, however, whatever is in your clipboard is pasted in, even though the event fires.
Component: Editor → Untriaged
Product: Core → Firefox
Version: unspecified → 50 Branch
Firefox: 50.0a1, Build ID: 20160626030213 User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0 I have tested this issue on the latest Firefox (47.0) release and latest Nightly (50.0a1) build. When testing this I have used both provided test cases. In the test case from comment 0, when pressing the "Insert Text" link, nothing happens. In Chrome when pressing the "Insert Text" link in the text box the "Text" string is displayed. In the test case from comment 3, any copied string is pasted in the text box, but the "This should be pasted." string should be pasted.
Status: UNCONFIRMED → NEW
Component: Untriaged → Editor
Ever confirmed: true
Product: Firefox → Core
I'm not sure if comment 3's testcase is exactly same bug as this. Here is the simplest testcase: https://jsfiddle.net/d_toybox/prkt4yhd/1/ Anyway, according to MDN, document.execCommand() is designed only for designMode="on" or "contenteditable". So, it's not working with <input> nor <textarea> must be intentional behavior in Gecko. https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand However, indeed, it makes incompatibility between other browsers. This is too bad. I guess that it's not so difficult to implement this, but I don't have much time because there are a lot of bugs in my queue...
According to the debugger, we hit here because there is no HTML editor in the testcase: https://dxr.mozilla.org/mozilla-central/rev/6608e5864780589b25d5421c3d3673ab30c4c318/dom/html/nsHTMLDocument.cpp#3146-3149 And I guess we need to hack here: https://dxr.mozilla.org/mozilla-central/rev/6608e5864780589b25d5421c3d3673ab30c4c318/dom/html/nsHTMLDocument.cpp#3193-3199 We need to use command manager for <input> or <textarea> instead of HTML editor's. I guess that this bug is useful for Gecko Hands-on which will be held in Japan late this month. I'll research the detail more and new hacker should fix this bug if it's possible.
Assignee: nobody → masayuki
Thank you for looking into this! Do you know what, if anything, the spec says here?
(In reply to Boris Zbarsky [:bz] from comment #7) > Thank you for looking into this! Do you know what, if anything, the spec > says here? Although, not yet reading whole of the the Editing API draft, I don't find about the target of execCommand. I feel odd to use "document."execCommand for an editable element, though. (<input>.execCommand makes sense for me...)
This bug becomes more important since setting `.value` now nukes undo history for <textarea>s and <input>s. If developers want to preserve undo history for <textarea>s and <input>s, they would use `execcommand` on Webkit and directly use .value on Firefox. Now, there is no way for preserving undo history while programmatically changing <textarea> or <input> values.
Please also refer to https://twitter.com/FakeU/status/901671863851429889 for illustration.
Whiteboard: [specification][type:bug] → [specification][type:bug][parity-blink][parity-edge]
You need to log in before you can comment on or make changes to this bug.