Upgrading a custom element in a chrome mochitest causes a crash
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: tgiles, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
text/plain
|
Details |
STR:
- Patch this phabricator revision
- Use either an artifact or full build
- Run
./mach test toolkit/content/tests/widgets/test_moz_support_link.html
Expected results:
- Test does not crash
Actual results:
- Test crashes due to a check at line 1249 in CustomElementRegistry
Attached is an error log that shows the crash trace when I run the test.
This might be a mochitest chrome test harness issue because the support-link component works as expected in Firefox. If you build and run using the previously indicated phabricator revision, you can see this support link component in about:preferences next to the "Enable Container Tabs" checkbox.
:emilio's initial hunch is that there's a broken custom element definition. How would I be able to confirm that?
Reporter | ||
Comment 1•2 years ago
|
||
Reporter | ||
Comment 2•2 years ago
|
||
For additional context, I'm basically trying to convert the SupportLink custom element that exists in aboutaddons.js into a reusable component (i.e. pull the code up to toolkit/content/widgets/
). I haven't found any instances of this particular element under test but we should have tests for upgrading custom elements right?
Comment 3•2 years ago
|
||
I assume https://searchfox.org/mozilla-central/rev/70bc66e002ad1cdb1fe5d77428803432f261038a/dom/base/CustomElementRegistry.cpp#447 fails on a debug build?
Reporter | ||
Comment 4•2 years ago
|
||
I sent off a Try run, https://treeherder.mozilla.org/jobs?repo=try&revision=908e67a0f928c784e12df708a7af9b49652f122c&selectedTaskRun=YXrKDNBtRn6yfSv5fbEL0Q.0, and it does appear that I'm getting an error of Assertion failure: definition (Callback should define the definition of type.), at /builds/worker/checkouts/gecko/dom/base/CustomElementRegistry.cpp:447
just as you predicted :smaug. I'm not sure how to decipher what this error means in this context though. As far as I can tell, I've defined the moz-support-link
widget type by creating moz-support-link.mjs
and defining this type on customElements
via customElements.define("moz-support-link, MozSupportLink, { extends: "a"});
. Otherwise I'm guessing the Callback should define the definition of type
is yelling due to something I've added in customElements.js
? I guess I can't call import()
inside of this element creation callback?
Reporter | ||
Comment 5•2 years ago
|
||
FWIW, we've figured out a workaround to this issue. It involves not using the customElements.setElementCreationCallback
function for the newly created moz-support-link
component but instead importing XPCOMUtils
as needed in the moz-support-link.mjs
module as well as the test_moz_support_link.html
. I'm not familiar enough with the mochitest chrome environment to know why XPCOMUtils
are not available by default in that particular environment, but using these approaches allows us to avoid the consistent crash in the test_moz_support_link.html
test.
Comment 6•2 years ago
|
||
edgar said he could take a look. Thanks!
Updated•2 years ago
|
Comment 7•2 years ago
|
||
(In reply to Tim Giles [:tgiles] from comment #4)
I sent off a Try run, https://treeherder.mozilla.org/jobs?repo=try&revision=908e67a0f928c784e12df708a7af9b49652f122c&selectedTaskRun=YXrKDNBtRn6yfSv5fbEL0Q.0, and it does appear that I'm getting an error of
Assertion failure: definition (Callback should define the definition of type.), at /builds/worker/checkouts/gecko/dom/base/CustomElementRegistry.cpp:447
just as you predicted :smaug. I'm not sure how to decipher what this error means in this context though.
We expect the custom element will be defined in elementCreation
callback as the callback is designed to have a way to know when to define CE lazily.
As far as I can tell, I've defined the
moz-support-link
widget type by creatingmoz-support-link.mjs
and defining this type oncustomElements
viacustomElements.define("moz-support-link, MozSupportLink, { extends: "a"});
. Otherwise I'm guessing theCallback should define the definition of type
is yelling due to something I've added incustomElements.js
? I guess I can't callimport()
inside of this element creation callback?
I don't see customElements.define
got called during elementCreation
callback, and from https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import, it seems to me that import()
loads an ECMAScript module asynchronously. Could we load moz-support-link.mjs
synchronously in elementCreation
callback, I expect with that we won't hit the assertion anymore.
Reporter | ||
Comment 8•2 years ago
|
||
So I wonder if this bug is a dupe of Bug 1803810 then, since that bug deals with supporting synchronous loading of ESMs. Currently we can't use the import * from "xyz.mjs
syntax within the setElementCreationCallback
, and trying to use ChromeUtils.importESModule("chrome://global/content/elements/moz-support-link.mjs")
doesn't seem to work (which I think is 1803810).
Comment 9•2 years ago
|
||
Since the crash is expected if we don't define the custom element synchronously in elementCreation callback, lets close this one. We could track the the supporting of synchronous loading ESMs in bug 1803810 or bug 1803678.
Updated•2 years ago
|
Description
•