1843741 - Thunderbird Crash in [@ nsWindowWatcher::OpenWindowInternal]

Status: VERIFIED FIXED

(Thunderbird :: General, defect, P1)

Description

[Wayne Mery (:wsmwk)]

Crash report: https://crash-stats.mozilla.org/report/index/029542de-13e0-4cf2-89fa-3c8ab0230713 Thunderbird 115 - user's comment "Tried to access the telemetry settings, and clicking on the link crashed Thunderbird."

MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(targetBC->GetOpenerId() == parentBC->Id())

Top 10 frames of crashing thread:

0  xul.dll  nsWindowWatcher::OpenWindowInternal  toolkit/components/windowwatcher/nsWindowWatcher.cpp:1098
1  xul.dll  nsWindowWatcher::OpenWindow2  toolkit/components/windowwatcher/nsWindowWatcher.cpp:389
2  xul.dll  nsGlobalWindowOuter::OpenInternal  dom/base/nsGlobalWindowOuter.cpp:7032
3  xul.dll  nsGlobalWindowOuter::OpenNoNavigate  dom/base/nsGlobalWindowOuter.cpp:5713
4  xul.dll  nsDocShell::PerformRetargeting  docshell/base/nsDocShell.cpp:8585
5  xul.dll  nsDocShell::InternalLoad  docshell/base/nsDocShell.cpp:9265
6  xul.dll  nsDocShell::OnLinkClickSync  docshell/base/nsDocShell.cpp:13107
7  xul.dll  OnLinkClickEvent::Run  docshell/base/nsDocShell.cpp:12793
8  xul.dll  mozilla::RunnableTask::Run  xpcom/threads/TaskController.cpp:555
9  xul.dll  mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal  xpcom/threads/TaskController.cpp:879

Comment 1

[Magnus Melin [:mkmelin]]

Don't know what's going on sorry.

Comment 2

[Wayne Mery (:wsmwk)]

#55 crash for 115.2.2

Comment 3

[Wayne Mery (:wsmwk)]

Is this one any better? bp-b3fa4f0a-4932-47b4-ac6b-2edc60230817 "it crashed when trying to check profile information"

Comment 4

[Makoto Kato [:m_kato]]

(In reply to Wayne Mery (:wsmwk) from comment #3)

Is this one any better? bp-b3fa4f0a-4932-47b4-ac6b-2edc60230817 "it crashed when trying to check profile information"

I don't know. But most crashes are assertion MOZ_RELEASE_ASSERT(targetBC->GetOpenerId() == parentBC->Id());. So, when opening dialog window, opener (parent) window is closed unfortunately before opening new dialog window. So this issue depends on dialog / window.

Comment 5

[Wayne Mery (:wsmwk)]

Reading bug 1670821 more closely, it is perhaps understandable that Thunderbird has the majority of crashes? "Crashing when testing a page in a non-Fission window with Fission enabled is somewhat understandable, as the code for opening new windows doesn't always handle launching like this super well. Given that we don't intend to support "Open new non-fission window" in the long term"

The only newer version Firefox crash with the same assertion is bp-a6a19da5-c7af-46d7-94c4-d8dc00230831 Firefox 116

bp-6f764f14-5a85-4189-b9c4-732860240126 Firefox 123
bp-8243f9f8-5b09-4910-9f4c-889d10231213 "no longer access to the original profile folder after update" Thunderbird 115
bp-e8ddfc8f-ce68-45a8-816c-70d0a0231210 "in troubleshoot mode, with setting reset and add-ons disabled, clicked about:memory, and it crashed. When not in troubleshoot mode, about:memory spins forever (and TB is taking about 12GB of ram..)" Thunderbird 115

Comment 6

[Wayne Mery (:wsmwk)]

I crashed consistently on nightly build on Mac clicking about:profiles on nightly buildid 20240306105810. Both with MOZ_DIAGNOSTIC_ASSERT(!windowIsNew || targetDocShell). beta 121.0b6 does not crash.

bp-629af425-9df3-406a-a1ca-63e4c0240306
bp-ff876192-ed56-4e54-96d9-341e60240306

Comment 7

[Wayne Mery (:wsmwk)]

I clicked "All crash reports" in help > Troubleshooting Information. bp-9ff164e8-f9b6-45dc-be0f-202ff0240324 125.0b1

Also signature @0x0 | nsWindowWatcher::OpenWindowInternal

Comment 8

[Alessandro Castellani [:aleca]]

Assigning this to Ikey and setting P1/S1 since this makes TB crash for every link in the troubleshooting info page.

Comment 9

[Wayne Mery (:wsmwk)]

This is #1 crash for 125.0 beta and alpha.

Compared to 124.0 beta where it ranks much lower at #11. ... graphed

There must be some regressive aspect to the version 125.0x crashes, and the increase in 125.0x is entirely Windows users.

Comment 10

[Wayne Mery (:wsmwk)]

The first recent nightly crash of the last three months starts with buildid 20240304095714 with a steady rate of crashes since then.

That's a Monday build, so the regression checkin likely occurred Feb 27-March 4. If it's highly reproducible should be easy to find the regressing patch checkin

Comment 11

[Wayne Mery (:wsmwk)]

Nightly build 20240301111143 on Windows doing about:telemetry does NOT crash.

Comment 12

[Wayne Mery (:wsmwk)]

Windows 2020312 build crashed with about:telemetry with MOZ_CRASH reason MOZ_DIAGNOSTIC_ASSERT(!windowIsNew || targetDocShell)

Comment 13

[Emilio Cobos Álvarez (:emilio)]

I get this crash by going to troubleshooting information and clicking about:memory: https://crash-stats.mozilla.org/report/index/bp-13617984-bbae-4b6b-b105-a44130240401

Comment 14

[Ikey Doherty]

OK still looking into this now but it's interesting to note the targetDocShell is null.

It's also down to the use of target="_blank", investigating further.

diff --git a/mail/components/about-support/content/aboutSupport.xhtml b/mail/components/about-support/content/aboutSupport.xhtml
--- a/mail/components/about-support/content/aboutSupport.xhtml
+++ b/mail/components/about-support/content/aboutSupport.xhtml
@@ -207,7 +207,7 @@
             <th class="column" data-l10n-id="app-basics-memory-use"/>
 
             <td>
-              <a href="about:memory" target="_blank">about:memory</a>
+              <a href="about:memory">about:memory</a>
             </td>
           </tr>

Comment 15

[Ikey Doherty]

Attachment: Bug 1843741 - Stop overriding remote for blank targets. r=#thunderbird-reviewers

The prior change seems to have landed between fixes, as it then caused the links
on our troubleshooting page to stop working, by forcibly removing their docShell.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/f431291dcef7
Stop overriding remote for blank targets. r=aleca,darktrojan

Comment 17

[Ikey Doherty]

Attachment: Bug 1843741 - Follow up fix for racey tests. r=#thunderbird-reviewers

As pointed out by mkmelin, there is some potential for raciness in the
testing where we could miss the click event.

We address this now rather than wait for a mystery intermittent test
failure to appear.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/1b838f730f95
Follow up fix for racey tests. r=mkmelin

Comment 19

[Wayne Mery (:wsmwk)]

Thanks Ikey, nightly crashes have ended.

Comment 20

[Wayne Mery (:wsmwk)]

Ikey,
Are you good for us uplifting this to 115 esr?

Comment 21

[Wayne Mery (:wsmwk)]

It's a low rate crash on 115, so let's skip uplift there. But ...

Comment 22

[Wayne Mery (:wsmwk)]

Ikey,
There have still been crashes in beta 126, 127, 128.

128.0b1 https://crash-stats.mozilla.org/report/index/c66ef986-49d6-4d0f-98c5-63aa10240619

Comment 23

[Wayne Mery (:wsmwk)]

No beta 132 crashes thus far, which would be a positive sign, except a third of beta users are still on beta 131 a week after balrog update rate 100.
https://crash-stats.mozilla.org/signature/?product=Thunderbird&version=%21115.15.0esr&version=%21115.14.0esr&version=%21115.13.0esr&version=%21115.12.0esr&signature=nsWindowWatcher%3A%3AOpenWindowInternal&date=%3E%3D2024-04-12T08%3A20%3A00.000Z&date=%3C2024-10-12T08%3A20%3A00.000Z#summary

Comment 24

[Wayne Mery (:wsmwk)]

Checked the top 10 install time users on version 128, and none report other crash signatures.