Closed Bug 1804469 Opened 2 years ago Closed 2 years ago

Upgrading a custom element in a chrome mochitest causes a crash

Categories

(Core :: DOM: Core & HTML, defect)

defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: tgiles, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

Attached file crash-log (deleted) —

STR:

  1. Patch this phabricator revision
  2. Use either an artifact or full build
  3. Run ./mach test toolkit/content/tests/widgets/test_moz_support_link.html

Expected results:

  1. Test does not crash

Actual results:

  1. 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?

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?

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?

Flags: needinfo?(smaug)

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.

edgar said he could take a look. Thanks!

Flags: needinfo?(smaug) → needinfo?(echen)
Severity: -- → S3

(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 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?

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.

Flags: needinfo?(echen) → needinfo?(tgiles)

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).

Flags: needinfo?(tgiles)

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.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
Attachment #9307095 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: