Created attachment 276497 [details] Reproduction Open the attached .html file. It should alert "a" twice.
Note that fixing this bug should include making sure checkValidity() works correctly.
(In reply to comment #1) > Note that fixing this bug should include making sure checkValidity() works > correctly. fast/forms/checkValidity-cloneNode-crash.html should be updated when this occurs.
Firefox and Safari alert "a" once. Chrome alerts "a" twice.
Myles, why do you expect the textarea cloning to clone the value? I am looking at the spec but I cannot find the part that says we should (maybe I missed it or maybe it is a bug in the spec). There is what I found in the spec: https://dom.spec.whatwg.org/#concept-node-clone -> Says we should copy over all the element attributes, but 'value' is not a content attribute of textarea. -> Says to run any cloning steps defined for the element in other applicable specifications So I looked at the HTML spec for HTMLTextAreaElement but it does not seem to define any additional cloning steps: https://html.spec.whatwg.org/multipage/forms.html#htmltextareaelement The only cloning steps I find on this page are: "The cloning steps for input elements must propagate the value, dirty value flag, checkedness, and dirty checkedness flag from the node being cloned to the copy." However, HTMLTextAreaElement is not an input element (HTMLInputElement). So, unless I am mistaken, Firefox and Safari/WebKit both match the specification. Assuming I did not miss anything and you think we should clone the value, I suggest filing a bug against the HTML spec.
As far as I read the spec, this is a bug in Chrome and WebKit/Gecko behavior is what the spec mandates. It's somewhat surprising that input element's value is propagated during cloning.
Per HTML only <input>, <template>, and <script> have special cloning behavior. Rick, Philip, any idea why Chrome has this behavior for <textarea>?
To begin with, here's the code: https://chromium.googlesource.com/chromium/src/+blame/8400b8124886e7c94ce59b2e595ae74cee821f56/third_party/WebKit/Source/core/html/HTMLTextAreaElement.cpp#641 That was added in response to this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=487352 I haven't dug deeper into how this turned out this way, but will comment on the bug and point here.
Closing this bug as won't fix since WebKit's current behavior matches the spec and Gecko's behavior. Given this Chrome not matching the spec appears to be unintentional, I don't think we should change our behavior.
Rather than closing the bug now, if we will proceed by considering this a supported operation, we should add a test.
Reopening to attach new patch.
Created attachment 277322 [details] Patch
Comment on attachment 277322 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=277322&action=review We should probably add a more direct test for cloneNode which checks that the value property doesn't get copied over. > LayoutTests/ChangeLog:7 > + Please add a change log description.
Comment on attachment 277322 [details] Patch r=me
Created attachment 277323 [details] Patch
Committed r200069: <http://trac.webkit.org/changeset/200069>
Comment on attachment 277323 [details] Patch Clearing review flag given that this patch landed by comment #15.
Spec discussion on this: https://github.com/whatwg/html/issues/1233
Reopen given that the spec was updated got add cloning steps for Textarea: https://github.com/whatwg/html/pull/1784
Created attachment 288984 [details] Patch
Comment on attachment 288984 [details] Patch Attachment 288984 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/2081456 New failing tests: fast/forms/checkValidity-cloneNode-crash.html
Created attachment 288992 [details] Archive of layout-test-results from ews114 for mac-yosemite The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews114 Port: mac-yosemite Platform: Mac OS X 10.10.5
Comment on attachment 288984 [details] Patch Causing crashes.
Created attachment 289003 [details] Patch
Comment on attachment 289003 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=289003&action=review > Source/WebCore/html/HTMLTextAreaElement.cpp:598 > + updateValidity(); I was missing a call to updateValidity() here.
Comment on attachment 289003 [details] Patch Please file a new bug for this patch. This patch represents a change of behavior. We should not re-open this bug, which was fixed 5 months ago (comment #15) to conform to the spec. at the time.
Comment on attachment 289003 [details] Patch No, this bug was opened for this purpose, as per the title. At the time, we decided to hold off on making this change (and file a bug upstream). But now that the spec has been updated, we should do it. This is also the bug that is tracked upstream (by spec editors).
Comment on attachment 289003 [details] Patch Clearing flags on attachment: 289003 Committed r206026: <http://trac.webkit.org/changeset/206026>
All reviewed patches have been landed. Closing bug.