TypeError "class heritage customElements.get(...) is not an object or null" in mailWidgets.js during Thunderbird startup

RESOLVED FIXED in Thunderbird 66.0

Status

defect
RESOLVED FIXED
5 months ago
4 months ago

People

(Reporter: ssitter, Assigned: mkmelin)

Tracking

Thunderbird 66.0

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

Reporter

Description

5 months ago
During Thunderbird 66.0a1 (BuildID 20181221092739) startup the following error is reported in console:

> TypeError: class heritage customElements.get(...) is not an object or null
> mailWidgets.js:270:31 

The error is reported for class MozTreecolImage:
https://searchfox.org/comm-central/rev/ffaaa034245811ec92643f967733a39649f3b13c/mail/base/content/mailWidgets.js#270

Comment 1

5 months ago
Yes, I also see this constantly. Started in TB 65.
OS: Unspecified → All
Hardware: Unspecified → All
Version: 66 → 65

Updated

5 months ago
Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(arshdkhn1)
Assignee: nobody → arshdkhn1
Flags: needinfo?(arshdkhn1)
This is a racing issue. The mailWidgets custom elements are being loaded before the firefox custom elements are loaded so there is an error when treecolimage tries to extend treecol(fx custom element).
Posted patch treecolimage-bug.patch (obsolete) — Splinter Review
Attachment #9033395 - Flags: review?(mkmelin+mozilla)
Flags: needinfo?(mkmelin+mozilla)
Posted patch treecolimage-bug.patch (obsolete) — Splinter Review
using setElementCreationCb so that the class code is executed only when the treecol-image tag is encountered.. since this was a racing issue, this fixes the problem..
Attachment #9033395 - Attachment is obsolete: true
Attachment #9033395 - Flags: review?(mkmelin+mozilla)
Attachment #9033396 - Flags: review?(mkmelin+mozilla)
Posted patch treecolimage-bug.patch (obsolete) — Splinter Review
Attachment #9033396 - Attachment is obsolete: true
Attachment #9033396 - Flags: review?(mkmelin+mozilla)
Attachment #9033401 - Flags: review?(mkmelin+mozilla)
Assignee

Comment 6

4 months ago

In what way is it a racing issue?
If it's a racing issue, why would this make treecol-image work consistently? Of course it would remove the exception in the console for the cases where treecol isn't set yet, but for those cases, the treecol-image would not work, right?

(In reply to Magnus Melin [:mkmelin] from comment #6)

In what way is it a racing issue?
If it's a racing issue, why would this make treecol-image work consistently? Of course it would remove the exception in the console for the cases where treecol isn't set yet, but for those cases, the treecol-image would not work, right?

treecol-image is called a lot of times.. so for the first few times the treecol-image throws that exception/error but after sometime when treecol is available in scope, the further calls to get the custom element doesn't throw error/exeception.

IMO it is a racing issue in the way that the custom element code of TB is called earlier than FX's custom element code so the Tb custom element that depends/extends the fx's custom element will throw error/exception.

*treecol-image custom element definition is called many times, as the custom element code is attached to domWindowCreated event so maybe for the first few window creation event the fx custom elements are not loaded in scope but then later they are added to scope, I hope what I am sayin makes sense.

Comment 9

4 months ago

Kinda like bug 1519653?

Assignee

Comment 10

4 months ago

Why would there be more than one domWindowCreated event for a window?
I don't think the customElements.js is ever loaded more than once for a window.

(In reply to Magnus Melin [:mkmelin] from comment #10)

Why would there be more than one domWindowCreated event for a window?
I don't think the customElements.js is ever loaded more than once for a window.

the DOMWindowCreated is called on the creation of each window right?

Assignee

Comment 12

4 months ago

Yes, but the loaded customElements are put (only) into the scope of the specific window, so shouldn't leak between windows.

(In reply to Magnus Melin [:mkmelin] from comment #12)

Yes, but the loaded customElements are put (only) into the scope of the specific window, so shouldn't leak between windows.
yes you are right.

Assignee

Comment 14

4 months ago

Turns out the problem comes from loading the dummy document.

https://searchfox.org/comm-central/source/mozilla/toolkit/content/customElements.js#299

I don't know why that is loaded or what it's used for, but I'm pretty sure we don't need to load our elements into there.

Attachment #9039075 - Flags: review?(arshdkhn1)
Assignee

Updated

4 months ago
Assignee: arshdkhn1 → mkmelin+mozilla
Status: NEW → ASSIGNED
Assignee

Updated

4 months ago
Attachment #9033401 - Attachment is obsolete: true
Attachment #9033401 - Flags: review?(mkmelin+mozilla)
Attachment #9039075 - Flags: review?(arshdkhn1) → review+
Keywords: checkin-needed

Comment 15

4 months ago

Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/bffe1c0bac89
don't load the Thunderbird custom elements in the dummy.xul document. r=arshad

Status: ASSIGNED → RESOLVED
Last Resolved: 4 months ago
Keywords: checkin-needed
Resolution: --- → FIXED

Updated

4 months ago
Target Milestone: --- → Thunderbird 66.0

Comment 16

4 months ago

I was hoping this might fix Bug 1517818, but it doesn't.

You need to log in before you can comment on or make changes to this bug.