Closed Bug 1515953 Opened 6 years ago Closed 6 years ago

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

Categories

(Thunderbird :: General, defect)

Product:
Thunderbird
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 66.0

People

(Reporter: ssitter, Assigned: mkmelin)

Details

Attachments

(1 file, 3 obsolete files)

bug1515953_inherit_in_dummy.patch
(deleted), patch
arshad
: review+
Details | Diff | Splinter Review
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
Yes, I also see this constantly. Started in TB 65.
OS: Unspecified → All
Hardware: Unspecified → All
Version: 66 → 65
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).
Attached patch treecolimage-bug.patch (obsolete) (deleted) — — Splinter Review
Attachment #9033395 - Flags: review?(mkmelin+mozilla)
Flags: needinfo?(mkmelin+mozilla)
Attached patch treecolimage-bug.patch (obsolete) (deleted) — — 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)
Attached patch treecolimage-bug.patch (obsolete) (deleted) — — Splinter Review
Attachment #9033396 - Attachment is obsolete: true
Attachment #9033396 - Flags: review?(mkmelin+mozilla)
Attachment #9033401 - Flags: review?(mkmelin+mozilla)

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.

Kinda like bug 1519653?

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?

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.

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: arshdkhn1 → mkmelin+mozilla
Status: NEW → ASSIGNED
Attachment #9033401 - Attachment is obsolete: true
Attachment #9033401 - Flags: review?(mkmelin+mozilla)
Attachment #9039075 - Flags: review?(arshdkhn1) → review+

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
Closed: 6 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 66.0

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.

Attachment

General

Creator:
Created:
Updated:
Size: