document.createElement with options=undefined does not upgrade a custom element immediately
Reported by
steven...@gmail.com,
May 10 2018
|
||||||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Steps to reproduce the problem:
1. call document.createElement with a custom element tagname and undefined as second argument
2. the returned element does is not an instance of the custom element class
What is the expected behavior?
document.createElement("my-custom-element", undefined) should work the same as document.createElement("my-custom-element"), like it does in Firefox, because as shown in the test case, this can create errors with an alias function for document.createElement
What went wrong?
See the test case, the constructor is not called and the method of the custom element class cannot be found
Did this work before? N/A
Does this work in other browsers? Yes
Chrome version: 65.0.3325.183 (Vivaldi) Channel: stable
OS Version: 10.0
Flash Version:
I used Vivaldi to test this at first, but can also reproduce it with Chrome for Android 66.0.3359.158
,
May 10 2018
@woxxom What exactly do you mean? That in Chrome 66 this does not happen? Or that this is intended? Anyway, I stated that I tested this in Chrome 66 and it did not work. By the way, I do not think the commit mentioned concerns this issue, as it seems to be about upgrading elements after they have been created.
,
May 10 2018
Chrome 66 (stable channel) produces the correct output here. The commit listed above is found by bisecting Chromium snapshots. Older snapshots produced the error message mentioned inside bug.html. The commit has landed in 66.0.3345.0 and after that the output is correct in all newer builds, including the current stable.
,
May 10 2018
@woxxom Ah ok, thanks! Any idea why this apparently doesn't include Chrome for Android?
,
May 10 2018
,
May 15 2018
stevenwdv@, Could you please confirm issue got resolved in chrome as per C#4? Thanks..!
,
May 15 2018
I tested this in the newest version of Chrome and all tests passed. So I tested it on Android and also all tests passed. But when I opened my website it still gave an error on both versions... So apparently the issue was not fixed, rather due to the upgrading of elements when they are added to the DOM the issue didn't happen in the testcase. Therefore I modified the testcase (attachment coming up) to also include tests with elements not yet added to the DOM, and those still fail in Chrome (but succeed in Firefox). In the log you can see the constructor is not called until after the element is added too the DOM, *but only if the second argument to createElement was explicitly undefined*. PS: I know you didn't mean to but it's a bit weird you typed out my full email while non-chromium contributors can only see part of it.
,
May 15 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 15 2018
,
May 21 2018
,
May 28 2018
Attached the observations on the latest Chrome stable #66.0.3359.181. stevenwdv@ -- Could you please look into the screenshot attached and let us know the expected value to be seen in the console. It would help us in triaging the issue further. Thanks!
,
May 28 2018
Added attachment, and again, remember not everyone can see my full email address, others just see "steven..."
,
May 28 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 29 2018
stevenwdv@, Thanks for the reply. Able to reproduce the issue on Windows 10, Mac 10.13.3 & debian Rodate using chrome reported version-65.0.3325.183,stable-66.0.3359.181 and Canary- 68.0.3440.6 as per c#11 & C#13. Same issue observed from M60 builds.As it is non regression issue marking it as Untriaged to get it addressed from dev team. Please find the attached screenshot for reference.
,
May 29 2018
So do all @chromium.org people here type out full email addresses when addressing people? You know Monorail masks part of eg. @gmail.com addresses to protect privacy and make sure we do not receive unneccesary spam right? Or not? Does no-one read my comments?
,
May 30 2018
,
May 30 2018
Confirmed. Firefox Nightly and Safari TP work correctly. Document::CreateElementForBinding(const AtomicString&, const StringOrDictionary&, ExceptionState&) should call CreateElementForBindings(const AtomciString&, ExceptionState&) if the StringOrDictionary IsNull() is true.
,
Jun 5 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5b75317be92ce4335f19b594fee03ae0ae081328 commit 5b75317be92ce4335f19b594fee03ae0ae081328 Author: Justin Ribeiro <justin@justinribeiro.com> Date: Tue Jun 05 02:38:30 2018 custom-elements: Element created by createElement(name, options) with valid custom element name and options set to undefined should be upgraded createElement('my-element', undefined) was not being upgraded, though both createElement('my-element') and createElement('my-element', {}) were. Bug: 841725 Change-Id: Id43b21f8e1cad10745dedf3699691da7ad85cf03 Reviewed-on: https://chromium-review.googlesource.com/1084007 Commit-Queue: Kent Tamura <tkent@chromium.org> Reviewed-by: Kent Tamura <tkent@chromium.org> Cr-Commit-Position: refs/heads/master@{#564352} [modify] https://crrev.com/5b75317be92ce4335f19b594fee03ae0ae081328/AUTHORS [modify] https://crrev.com/5b75317be92ce4335f19b594fee03ae0ae081328/third_party/WebKit/LayoutTests/external/wpt/custom-elements/Document-createElement.html [modify] https://crrev.com/5b75317be92ce4335f19b594fee03ae0ae081328/third_party/blink/renderer/core/dom/document.cc
,
Jun 5 2018
,
Jun 12 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8b41ba1186cbd5c7306293fdc1650244fe7daf92 commit 8b41ba1186cbd5c7306293fdc1650244fe7daf92 Author: Kent Tamura <tkent@chromium.org> Date: Tue Jun 12 10:17:04 2018 custom-elements: Element created by createElementNS(ns, qname, options) with valid custom element name and undefined options should be upgraded immediately createElementNS(XHTML_NS, 'my-element', undefined) was not being upgraded immediatedly, though both createElementNS(XHTML_NS, 'my-element') and createElementNS(XHTML_NS, 'my-element', {}) were. Bug: 841725 Change-Id: Iccc4f0e98b1de65288381dd9ac106e71bfc5d0c8 Reviewed-on: https://chromium-review.googlesource.com/1096812 Reviewed-by: Yoichi Osato <yoichio@chromium.org> Commit-Queue: Kent Tamura <tkent@chromium.org> Cr-Commit-Position: refs/heads/master@{#566374} [modify] https://crrev.com/8b41ba1186cbd5c7306293fdc1650244fe7daf92/third_party/WebKit/LayoutTests/external/wpt/custom-elements/Document-createElementNS.html [modify] https://crrev.com/8b41ba1186cbd5c7306293fdc1650244fe7daf92/third_party/blink/renderer/core/dom/document.cc |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by woxxom@gmail.com
, May 10 2018