<textarea> should have useful cloning steps

[bzbarsky]

See https://bugzilla.mozilla.org/show_bug.cgi?id=230307#c14: everyone except Gecko copies the value and presumably dirty value flag. I have not tested whether it's the raw value that gets copied or whether the raw value on the clone gets set to the API value on the original.

[annevk]

Per https://bugs.webkit.org/show_bug.cgi?id=156637 WebKit removed this. Paging @cdumez and @rniwa.

[bzbarsky]

Hmm. Or never had it; I thought I had tested Safari, but clearly I screwed it up somehow, since it definitely doesn't copy the value when I test right now.

Given that, I'm less worried about the compat aspect, but it might still make sense to do this from a developer sanity point of view... I don't feel nearly as strongly about that, though.

[cdumez]

We did not remove anything, we merely chose not to change our behavior considering it matched the spec and Chrome. AFAIK, we never copied the value when copying a TextArea.

[cdumez]

So it seems to me that Firefox, WebKit and the spec are in agreement. That is not to say that textarea shouldn't have more useful cloning steps though, especially if Chrome already implements this.

@rniwa may have an opinion on this.

[annevk]

So only Chrome clones? Might be an @RByers matter then.

[bzbarsky]

Edge clones the value as well; I'm pretty sure I didn't mess up testing that. I didn't check IE11, but I could if that would be useful.

[rniwa]

Chrome also didn't copy the value until last year: https://bugs.chromium.org/p/chromium/issues/detail?id=487352

[domenic]

So right now we have:

• Firefox, WebKit, the spec: no cloning
• Edge, Chrome: cloning

It would have been really nice if Chrome had notified the standards community about their change so we could have had a cross-vendor discussion... I guess it was probably accidental, as per https://bugs.chromium.org/p/chromium/issues/detail?id=487352#c33.

I tend to agree it's more user-friendly to copy the textarea value like we copy other input values. Would Firefox and WebKit be interested in implementing such cloning steps, if we added them to the spec (and web-platform-tests)? Would they be opposed to adding them?

[bzbarsky]

I don't think I would be opposed. It's pretty simple to implement .... modulo that issue with raw value vs api value...

[RByers]

/cc @tkent-google

[tkent-google]

It seems I approved the TEXTAREA changes without checking the specification. I'm sorry for that!

IMO, cloning no TEXTAREA value is very inconsistent with cloning INPUT value, and cloning TEXTAREA value will help web authors. We should have cloning steps for all of stateful form controls.

[domenic]

On further testing it looks like Edge does not clone the textarea value: http://jsbin.com/jenaniciro/edit?html,output

This brings us to only 1/4 browsers cloning. Should we go for the shortest path to interop, and remove the cloning steps from Chrome? Or should we go for consistency and helpfulness to web authors, and add cloning steps?

[domenic]

Maybe one reason why it might be weird to copy the raw value while cloning is that that de-synchronizes the DOM tree from the raw value. That is, it makes it possible to have a textarea with no children, but with a raw value. I don't think it's possible to have that scenario otherwise.

[bzbarsky]

On further testing it looks like Edge does not clone the textarea value

It... depends. I was sure I hadn't screwed up testing edge on the testcase in https://bugzilla.mozilla.org/show_bug.cgi?id=230307, so I wrote more testcases. Compare http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4471 and http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4472 -- looks like Edge will clone the value (not just the default value, which is, of course, cloned in this case) if the clone is deep but not if the clone is shallow.

That is, it makes it possible to have a textarea with no children, but with a raw value.

This is the normal state of being for a textarea that had no initial value and then had its value modified, no?

[domenic]

looks like Edge will clone the value (not just the default value, which is, of course, cloned in this case) if the clone is deep but not if the clone is shallow.

That just seems really bad. Let's not introduce "deep cloning steps".

This is the normal state of being for a textarea that had no initial value and then had its value modified, no?

Ah, you're of course right; default value vs. value confusion strikes again.

---

So yeah, I guess I see two approaches still: add cloning steps (Chrome), or have none (Firefox, Safari). In either case Edge will have to change, either to add cloning steps for shallow clones too, or to remove them for deep clones.

[annevk]

I agree with @tkent-google that we should just make textarea consistent with input, even though I kinda dislike special cloning behavior. It also seems neither WebKit nor Gecko folks are opposed.

[domenic]

I'd like to get a bit more clarity from WebKit folks before saying we should go ahead with this. @cdumez, @rniwa, if we update the spec and web platform tests to have cloning steps, would you be OK with updating WebKit?

[cdumez]

Yes, I'd be willing to help aligning WebKit.

[domenic]

• Tests at Add tests for <textarea> cloning steps web-platform-tests/wpt#3734
• Commented on Gecko issue at https://bugzilla.mozilla.org/show_bug.cgi?id=230307#c18
• @cdumez reopened the WebKit issue at https://bugs.webkit.org/show_bug.cgi?id=156637#c18
• Filed Edge issue at https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8933049/

[cdumez]

The patch to align WebKit has landed:
http://trac.webkit.org/changeset/206026