Closed Bug 1584461 Opened 2 years ago Closed 2 years ago

Total Calendar Mozmill failure failure and total debug MozMill failure on 2019-09-27, Mochitests also failing


(Thunderbird :: Testing Infrastructure, defect)

Not set


(Not tracked)

Thunderbird 71.0


(Reporter: jorgk-bmo, Unassigned)


(Keywords: leave-open)

Looks like all Calendar Mozmill and Mochitests are failing on opt build and all Mozmill and Marionette tests are failing on debug builds with:

Assertion failure: false (Cross docGroup adoption is not allowed), at /builds/worker/workspace/build/src/dom/base/nsNodeUtils.h:213

Not hard to see that this comes from
Bug 1467970 - Unsupport cross docGroup adoption r=smaug

Olli, what can we do, looks like TB is totally smashed in debug builds.

Also NI Geoff for the Calendar failures.

Flags: needinfo?(geoff)
Flags: needinfo?(bugs)

Actually, some Calendar failures already started on this push:
but it got worse here:

Olli, what can we do, looks like TB is totally smashed in debug builds.

That appears to be incorrect. When built without Lightning, or with Lightning disabled, TB starts in a debug build. With Lightning enabled, it's crashes immediately with
Assertion failure: false (Cross docGroup adoption is not allowed), at c:/mozilla-source/comm-central/dom/base/nsNodeUtils.h:213
#01: AdoptNodeIntoOwnerDoc (c:\mozilla-source\comm-central\dom\base\nsINode.cpp: 1205)

Olli, what can we do, looks like TB is totally smashed in debug builds.

Well, that seems to be the case after all. Even without Calendar, opening a compose window just crashes.

Sorry about the flood of NIs but this is rather bad. Paul, could you take a look at the Calendar failures. You might have to do an opt build or back out M-C changeset c8a2c27a1128c4800c1fefc9fafd06204e48ec2a locally:

Flags: needinfo?(paul)
Keywords: leave-open

Confirming that with the backout of rev c8a2c27a1128c4800c1fefc9fafd06204e48ec2a, the compose window comes up again in a debug build.

Looks like we have two issues here: The one from bug 1467970 and some additional? calendar failures. Here's a try with the bug backed out:

Pushed by
temporarily disable Calendar for mass test failures. rs=bustage-fix CLOSED TREE

Could you not move nodes across docgroups?
Could you perhaps point to the exact code where the issue is happening? Which dom nodes are being moved to which document?
I would expect changed to be simple.

Flags: needinfo?(bugs) → needinfo?(jorgk)

Hmm, if this is for lightning, maybe the moves done by our overlay simulator? Overlays.jsm

Could you not move nodes across docgroups?

I'm not aware of any "docgroups". The compose window also crashes. And yes, with Lightning enabled, it crashes during start-up, most likely when the overlay loader gets active. Ah, it's dawning on me. I got the crash in the compose windows since I had an overlay add-on active. So that again points to the overlay loader.

We need to keep an eye on
with the M-C change backed out. Well, there we have a whole lot of Calendar failures which likely stem from some other source.
without Calendar, also too early to tell, but Linux debug is quite green as compared to totally orange before.

So summary:

I suggest to split this bug into two. I'll be out until about 19:00 GMT+2, so for roughly seven hours now.

Flags: needinfo?(jorgk)
Pushed by
Disabled Nightly builds. a=me CLOSED TREE

Disabled Nightly builds until we investigate this further. This was likely unnecessary but taken as a precaution EDIT: in case Calendar and other XUL add-ons fail even in an opt build. Also, I wanted to try this technique which hadn't been tried before, see bug 1568758 comment #1.

Pushed by
In calendar tests, stop looking for anonymous nodes that aren't anonymous; rs=bustage-fix
Load overlay documents in the same docGroup as the document they overlay; rs=bustage-fix
Closed: 2 years ago
Flags: needinfo?(paul)
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 71.0
You need to log in before you can comment on or make changes to this bug.