Setting the object element's name attribute need not propagate to the nested browsing context

[foolip]

Context:
https://bugs.chromium.org/p/chromium/issues/detail?id=632243

https://html.spec.whatwg.org/#the-object-element:attr-object-name-3 says "Whenever the name attribute is set, if the object element has a nested browsing context, its name must be changed to the new value. If the attribute is removed, if the object element has a browsing context, the browsing context name must be set to the empty string."

Here's an ad-hoc test:
https://software.hixie.ch/utilities/js/live-dom-viewer/saved/4353

No tested browser seems to do what the spec suggests here, so can it be dropped?

[foolip]

@xiaojunwu, you added the test in question in xiaojunwu/web-platform-tests@5e02231, any thoughts?

[annevk]

So <object> behaves the same as <embed> in practice? There's a whole bunch of bugs around these elements and their processing model needing to be more identical...

[foolip]

There appears to be some differences that involve the name attribute still in Blink, just not the one about propagation. Namely, object is a form-associated element where embed is not, but that's in the spec:
https://html.spec.whatwg.org/multipage/embedded-content.html#the-embed-element
https://html.spec.whatwg.org/multipage/embedded-content.html#the-object-element

I'm sure there are more quirky things hiding here, but I'll prepare a PR to drop the bit in question at least.

[foolip]

I went and found the commit where this was added: 0a2ab22

Here's a test of that "allow to load stuff in them" bit:
https://software.hixie.ch/utilities/js/live-dom-viewer/saved/4374

In Chrome, Edge and Firefox, "open in iframe" works but "open in object" just opens a new tab. So this thing didn't become reality, time to drop.