1316104 - CRASH [@ nsGlobalWindow::SetOpenerWindow] (with MOZ_RELEASE_ASSERT) when click link which opens link target in new TAB

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[Rainer Bielefeld]

Steps how to reproduce with official en-us SeaMonkey 2.49a1  (NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0 Build 20161107002359  (Default Classic Theme) on German WIN7 64bit:

1. Launch Browser (if you want: with blank new profile)
2. visit Google-Search <http://www.notebookcheck.com/Google-Suche.36689.0.html?cx=partner-pub-9323363027260837%3Atg143v-nekt&cof=FORID%3A10&ie=UTF-8&q=i3-5005U&sa=> (fom this Bug Report)
3. In page find string “Der Intel Core i3-5005U ist ein sparsamer” or
   in English search string “5. Jan. 2015”. 
   » finds a hit with "Intel inside"logo at the left 
4. Click Heading “Intel Core i3 5005U ...” with link
   » SM tries to open page → CRASH

Some crash reports:
bp-72d20d11-dc0a-40e9-b83c-d2b5b2161108        11/8/16	8:37 PM
bp-ad814c99-4d81-4fbb-9aae-de25c2161108        11/8/16	8:35 PM
bp-b1fd1efb-6b45-44f6-aac9-0abca2161108        11/8/16	8:26 PM
bp-d3182403-4a50-4f3c-9c65-8de392161108        11/8/16	8:25 PM

a) No crash if open new pate in step 4 with copy/paste URL or 
   'rightclick → open in new TAB'
b) reliably CRASH with any profile 8also newly created one)
c) no crash with 2.46 from September, REGRESSION

Comment 1

[Rainer Bielefeld]

MOZ_CRASH Reason MOZ_RELEASE_ASSERT(!contentOpener || !mTabGroup || mTabGroup == Cast(contentOpener)->mTabGroup)
Crash Reason 	EXCEPTION_BREAKPOINT

Comment 2

[Rainer Bielefeld]

It seems that any link on that search result page will CRASH

Comment 3

[Rainer Bielefeld]

d) FF 52.0a1 (2016-11-05) (32-bit) does not CRASH
   (opens links in new Window instead of new TAB)
   FF 52.0a1 (2016-11-08) (32-bit) also does not crash

Comment 4

[Frank-Rainer Grahl (:frg)]

I will try it out later but think its a valid bug. Looks like fallout from bug 1303196. 

Ratty could you look at this too. Likely another tabbrowser.xml change is needed.

Comment 5

[Frank-Rainer Grahl (:frg)]

Likely caused by this one:

https://hg.mozilla.org/mozilla-central/rev/24d65b1e1a76

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

Looks like TabGroup assert crash.

Comment 7

[Frank-Rainer Grahl (:frg)]

Attachment: 1316104-nsIBrowserDOMWindow-params.patch

The params for openURI changed. With the fix the crash no longer occurs and the search result opens ok in a new window. Still need to check if something else needs porting.

Comment 8

[Frank-Rainer Grahl (:frg)]

Thunderbird is likely also affected:

mail/base/content/mailWindow Line 554 uses the same code as Firefox.

Comment 9

[Nika Layzell [:nika] (ni? for response)]

(In reply to Frank-Rainer Grahl from comment #7)
> Created attachment 8809081 [details] [diff] [review]
> 1316104-nsIBrowserDOMWindow-params.patch
> 
> The params for openURI changed. With the fix the crash no longer occurs and
> the search result opens ok in a new window. Still need to check if something
> else needs porting.

You probably also want to check the other added flag in order to correctly support noopener - namely when that flag is not set you want to be sure to set the opener on the newly opened window, and when the flag is set you want to make sure not to set the opener. The opener must now be set wthin the openURI function because it must happen before the first document is loaded in the outer window.

Comment 10

[Philip Chee]

Comment on attachment 8809081 [details] [diff] [review]
1316104-nsIBrowserDOMWindow-params.patch

r=me a=me if tree needs APPROVAL

Comment 11

[Frank-Rainer Grahl (:frg)]

https://hg.mozilla.org/comm-central/rev/0fa8bfa73cdec9511df0395c2b1f3af2e5fa2b83

Leaving open to look into the other needed changes.

Comment 12

[Rainer Bielefeld]

This one is more serious than I thought at the beginning.
On <https://seamonkeyde.wordpress.com/2016/11/07/wird-seamonkey-noch-weiter-entwickelt/> I modified link behind "48 gefixte" so that source contains a 'target="_blank"' for the link; next line "75 gefixte" is without that modification and will open the link target in the currently focussed TAB.

Now click on "48 gefixte"  will cause a crash, "75 gefixte" will not.

Comment 13

[Rainer Bielefeld]

e) The crash is related to a particular preference, see workaround 
   in user_story_header

Comment 15

[Tony Mechelynck [:tonymec]]

[@ nsGlobalWindow::SetOpenerWindow] was SeaMonkey #1 topcrash with over 60% this past week, and climbing fast for Firefox (#55 up 92 places in a week "by build date")

Comment 16

[Tony Mechelynck [:tonymec]]

This bug was supposedly "fixed for SeaMonkey 2.49" on november 9; yet I crashed in both the 2016-11-10 and the 2016-11-11 nightlies when left-clicking links targeting a new tab, at times when my preference (as mentioned in the User Story) was "A new tab in the same window". See bug 1316950 (currently  duped to this one) for details.

IMHO "status-seamonkey-2.49: fixed" is misleading, and should be set back to "affected"

Comment 17

[Frank-Rainer Grahl (:frg)]

Tony: Could you provide a public url which crashes SeaMonkey. I am not using gmail. So far I am unable to reproduce this with a current local build.

FRG

Comment 18

[Tony Mechelynck [:tonymec]]

(In reply to Frank-Rainer Grahl from comment #17)
> Tony: Could you provide a public url which crashes SeaMonkey. I am not using
> gmail. So far I am unable to reproduce this with a current local build.
> 
> FRG

Hmm... The only case I had which wasn't on gmail was behind a password which I am not at liberty to divulge; OTOH I have now applied the "workaround" mentioned in the User Story of this bug, so for the time being I don't get any more crashes, even if I forget to use "Right-click → Open link in a new tab", which didn't crash for me.

Searching Socorro for crashes with this signature in the last 7 days, i.e. https://crash-stats.mozilla.com/search/?signature=%3DnsGlobalWindow%3A%3ASetOpenerWindow&date=%3E%3D2016-11-06T18%3A00%3A40.000Z&date=%3C2016-11-13T18%3A00%3A40.000Z&_sort=-build_id&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#crash-reports shows crashes for Firefox up to build ID 20161112030203 and for SeaMonkey up to build ID 20161111003001 which is later than comment #11 by almost 2 days. (No Thunderbird crashes, BTW.)

If you want to repeat the search at a later date, be sure to click "7 days" under the from-to dates to update them.

Comment 19

[Tony Mechelynck [:tonymec]]

frg: The crash happens at dom/base/nsGlobalWindow.cpp:3231-3232 (with line numbers for the current mozilla-central source); AFAIK this is Core source. Shall we give the Core guys the hot potato? I can try to reproduce the bug in the latest Firefox nightly to make sure they haven't yet fixed it (I doubt it, since the latest change in that file was on 2016-11-08 which is earlier than the build ID of the latest Firefox crash).

Comment 20

[Tony Mechelynck [:tonymec]]

I'll be afk for maybe 24 hours so I'll summarize my findings so far:

- Crash started happening on 7 november in both Firefox and SeaMonkey. Socorro records no Thunderbird crash, possibly because targeting a new tab in the same window of the same app is not possible in Thunderbird.
- Crash happens when left-clicking a link meant to open a new window, but only if the user's Preferences (or Options) direct that kind of link to "a new tab in the current window".
- Crash happens only on left-click, never on "Right-click → Open in a new tab".

Crash details for SeaMonkey can be found here and in duplicate bug 1316950. Here are crash details from the latest Firefox crash (so far) with this signature found on Socorro (comparing this Windows Firefox crash with the Linux SeaMonkey crash in bug 1316950 comment #0 shows that they are essentially the same crash):

bp-74f97580-c401-46f5-823a-3acdd2161113

20161112030203
https://hg.mozilla.org/mozilla-central/rev/fc104971a4db41e38808e6412bc32e1900172f14

Signature 	nsGlobalWindow::SetOpenerWindow More Reports Search
UUID 	74f97580-c401-46f5-823a-3acdd2161113
Date Processed 	2016-11-13 05:35:54
Uptime 	1,498 seconds (24 minutes and 58 seconds)
Last Crash 	1,633 seconds before submission (27 minutes and 13 seconds)
Install Age 	53,470 seconds since version was first installed (14 hours, 51 minutes and 10 seconds)
Install Time 	2016-11-12 14:44:34
Product 	Firefox
Release Channel 	nightly
Version 	52.0a1
Build ID 	20161112030203
OS 	Windows 7
OS Version 	6.1.7601 Service Pack 1
Build Architecture 	amd64
Build Architecture Info 	family 6 model 23 stepping 10 | 2
Adapter Vendor ID 	

0x10de

Adapter Device ID 	

0x0614

Startup Crash 	

False

MOZ_CRASH Reason 	MOZ_RELEASE_ASSERT(!contentOpener || !mTabGroup || mTabGroup == Cast(contentOpener)->mTabGroup)
Crash Reason 	EXCEPTION_BREAKPOINT
Crash Address 	0x7fede36bac3
User Comments 	
Total Virtual Memory 	8,796,092,891,136 bytes (8 TB)
Available Virtual Memory 	8,794,730,262,528 bytes (8 TB)
Available Page File 	5,750,996,992 bytes (5.36 GB)
Available Physical Memory 	2,324,381,696 bytes (2.16 GB)
System Memory Use Percentage 	45
EMCheckCompatibility 	

False

App Notes 	

AdapterVendorID: 0x10de, AdapterDeviceID: 0x0614, AdapterSubsysID: 00000000, AdapterDriverVersion: 9.18.13.4196
FP(D00-L1000-W00001100-T0000) D2D1.1? DWrite? DWrite+ D2D1.1+ D3D11 Layers? D3D11 Layers+ 

Processor Notes 	processor_ip-172-31-25-135_1308; MozillaProcessorAlgorithm2015; skunk_classifier: reject - not a plugin hang

Bugzilla - Report this bug in Firefox Core External Software Affecting Firefox Toolkit
Related Bugs

    1316950RESOLVED DUPLICATE Crash in nsGlobalWindow::SetOpenerWindow when (left-)clicking a link
    1316104ASSIGNED --- CRASH [@ nsGlobalWindow::SetOpenerWindow] (with MOZ_RELEASE_ASSERT) when click link which opens link target in new TAB

Crashing Thread (0)
Frame 	Module 	Signature 	Source
0 	xul.dll 	nsGlobalWindow::SetOpenerWindow(nsPIDOMWindowOuter*, bool) 	dom/base/nsGlobalWindow.cpp:3232
1 	xul.dll 	nsWindowWatcher::ReadyOpenedDocShellItem(nsIDocShellTreeItem*, nsPIDOMWindowOuter*, bool, bool, mozIDOMWindowProxy**) 	embedding/components/windowwatcher/nsWindowWatcher.cpp:2148
2 	xul.dll 	nsWindowWatcher::OpenWindowInternal(mozIDOMWindowProxy*, char const*, char const*, char const*, bool, bool, bool, nsIArray*, bool, bool, nsIDocShellLoadInfo*, mozIDOMWindowProxy**) 	embedding/components/windowwatcher/nsWindowWatcher.cpp:1061
3 	xul.dll 	nsWindowWatcher::OpenWindow2(mozIDOMWindowProxy*, char const*, char const*, char const*, bool, bool, bool, nsISupports*, bool, bool, nsIDocShellLoadInfo*, mozIDOMWindowProxy**) 	embedding/components/windowwatcher/nsWindowWatcher.cpp:442
4 	xul.dll 	nsGlobalWindow::OpenInternal(nsAString_internal const&, nsAString_internal const&, nsAString_internal const&, bool, bool, bool, bool, bool, nsIArray*, nsISupports*, nsIDocShellLoadInfo*, bool, nsPIDOMWindowOuter**) 	dom/base/nsGlobalWindow.cpp:12445
5 	xul.dll 	nsGlobalWindow::OpenNoNavigate(nsAString_internal const&, nsAString_internal const&, nsAString_internal const&, nsPIDOMWindowOuter**) 	dom/base/nsGlobalWindow.cpp:8346
6 	xul.dll 	nsDocShell::InternalLoad(nsIURI*, nsIURI*, bool, nsIURI*, unsigned int, nsIPrincipal*, nsIPrincipal*, unsigned int, nsAString_internal const&, char const*, nsAString_internal const&, nsIInputStream*, nsIInputStream*, unsigned int, nsISHEntry*, bool, nsAString_internal const&, nsIDocShell*, nsIURI*, nsIDocShell**, nsIRequest**) 	docshell/base/nsDocShell.cpp:10044
7 	xul.dll 	nsDocShell::OnLinkClickSync(nsIContent*, nsIURI*, char16_t const*, nsAString_internal const&, nsIInputStream*, nsIInputStream*, nsIDocShell**, nsIRequest**) 	docshell/base/nsDocShell.cpp:14019
8 	xul.dll 	OnLinkClickEvent::Run() 	docshell/base/nsDocShell.cpp:13798
9 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp:1216
10 	xul.dll 	mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp:96
11 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc:225
12 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc:205
13 	xul.dll 	nsBaseAppShell::Run() 	widget/nsBaseAppShell.cpp:156
14 	xul.dll 	nsAppShell::Run() 	widget/windows/nsAppShell.cpp:262
15 	xul.dll 	nsAppStartup::Run() 	toolkit/components/startup/nsAppStartup.cpp:283
16 	xul.dll 	XREMain::XRE_mainRun() 	toolkit/xre/nsAppRunner.cpp:4467
17 	xul.dll 	XREMain::XRE_main(int, char** const, nsXREAppData const*) 	toolkit/xre/nsAppRunner.cpp:4600
18 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:4691
19 	firefox.exe 	do_main 	browser/app/nsBrowserApp.cpp:282
20 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:115
21 	firefox.exe 	__scrt_common_main_seh 	f:/dd/vctools/crt/vcstartup/src/startup/exe_common.inl:253
22 	kernel32.dll 	BaseThreadInitThunk 	
23 	ntdll.dll 	RtlUserThreadStart 	
24 	kernel32.dll 	BasepReportFault 	
25 	kernel32.dll 	BasepReportFault

Comment 21

[Frank-Rainer Grahl (:frg)]

Per comment 9 I still need to check and port additional opener code code but could you try it in a fresh profile. It may be add-on related.

FRG

Comment 22

[Frank-Rainer Grahl (:frg)]

Attachment: 1316104-typo-fix.patch

I goofed and nobody noticed :) The good thing I can now reproduce the crash pretty easily. Not setting review yet.

FRG

Comment 23

[Jorg K (CEST = GMT+2)]

Comment on attachment 8810417 [details] [diff] [review]
1316104-typo-fix.patch

Review of attachment 8810417 [details] [diff] [review]:
-----------------------------------------------------------------

::: suite/browser/navigator.js
@@ +346,5 @@
>  }
>  
>  nsBrowserAccess.prototype = {
>    openURI: function openURI(aURI, aOpener, aWhere, aFlags) {
> +    var isExternal = !!(aFlags & Components.interfaces.nsIBrowserDOMWindow.OPEN_EXTERNAL);

I landed "Components.interfaces. ... ;-)

https://hg.mozilla.org/comm-central/rev/1d2132213242cb7967889420a3d1ff2e490c3e71#l1.17

Comment 24

[Philip Chee]

Comment on attachment 8810417 [details] [diff] [review]
1316104-typo-fix.patch

just a few lines up is
> const nsIBrowserDOMWindow = Components.interfaces.nsIBrowserDOMWindow;
So you can just do (aFlags & nsIBrowserDOMWindow.OPEN_EXTERNAL)

Comment 25

[Philip Chee]

>>  nsBrowserAccess.prototype = {
>>    openURI: function openURI(aURI, aOpener, aWhere, aFlags) {
>> +    var isExternal = !!(aFlags & Components.interfaces.nsIBrowserDOMWindow.OPEN_EXTERNAL);
> 
> I landed "Components.interfaces. ... ;-)
See Comment 24

Comment 26

[Nika Layzell [:nika] (ni? for response)]

The assertion which you are running into (!contentOpener || !mTabGroup || mTabGroup == Cast(contentOpener)->mTabGroup) is ensuring that the opener property of an outer window is set before the first document is loaded into that outer window. The fix in your situation is probably similar to the changes which were required for android in my original patch, namely you need to make sure that if an opener is passed in through openURI, that you correctly set the opener window on the created tab before the xul:browser element is attached to the DOM, which creates the initial document.

You may want nsIDOMChromeWindow::SetOpenerForInitialContentBrowser or nsXULElement::PresetOpenerWindow to cache the value before the element is attached to the DOM.

Comment 27

[Jorg K (CEST = GMT+2)]

(In reply to Philip Chee from comment #24)
> just a few lines up is
> > const nsIBrowserDOMWindow = Components.interfaces.nsIBrowserDOMWindow;
> So you can just do (aFlags & nsIBrowserDOMWindow.OPEN_EXTERNAL)
Thanks, done:
https://hg.mozilla.org/comm-central/rev/9245026f182fb3f20c12698d7197b3938c88b6f8

Comment 28

[Frank-Rainer Grahl (:frg)]

You are too fast. Didn't set review because I ran exactly into to problem Michael mentioned. With the broken fix it dind't crash so much:)  Needs some more work and a suite tabbrowser.xml change.

Comment 29

[Jorg K (CEST = GMT+2)]

(In reply to Frank-Rainer Grahl from comment #28)
> You are too fast.
I removed obvious clumsiness. No need to wait. We can follow up with a real fix if someone tells me how to test this.

> Didn't set review because I ran exactly into to problem
> Michael mentioned. With the broken fix it dind't crash so much:)
Sure, since it stops on 'Ci' being undefined.

Comment 30

[Tony Mechelynck [:tonymec]]

Hohoh! There is something wrong in the Tracking Flags: 2.49 (which is now Aurora) has disappeared, and what used to be the tracking flags for 2.49 have been renamed 2.50, rather than keeping 2.49 as-is and adding 2.50, which would IMHO have been more sensible.

Anyway, beware that current tinderbox-builds are already 2.50a1, 2.49a2, and I expect that the nightlies which will be published in a few hours will bear the same version numbers.

There is already a 2.50a1 20161114103108, i.e. 1½ hour after comment #27. I'm going to test it without the workaround: this bug really bugs me ;-)

Comment 31

[Tony Mechelynck [:tonymec]]

bp-535f4b7d-9edd-4f98-8085-ed1472161115 (Failure).

This 2.50a1 tinderbox-build has no symbols, but with the help of its http://ftp.mozilla.org/pub/seamonkey/tinderbox-builds/comm-central-trunk-linux64/1479148268/seamonkey-2.50a1.en-US.linux-x86_64.crashreporter-symbols-full.zip (file libxul.so/ABF8631A712F79338770CED57DF32AA60/libxul.so.sym, and beware: that zipfile is enormous, and even that .sym file is more than 400,000 bytes) it can be seen that the stack top, libxul.so@0x1557a2b, is indeed nsGlobalWindow::SetOpenerWindow line 3231.

Comment 32

[Tony Mechelynck [:tonymec]]

(In reply to Jorg K (GMT+1) from comment #29)
> (In reply to Frank-Rainer Grahl from comment #28)
> > You are too fast.
> I removed obvious clumsiness. No need to wait. We can follow up with a real
> fix if someone tells me how to test this.

If you receive github email messages about issues etc., and can read them by webmail, check if there is a "View it on GitHub" link near the bottom. Clicking this (with other-window links redirected to another tab of the current window) crashes for me in Gmail webmail; I suppose (but cannot check) that it would also crash in other webmail providers.

Comment 33

[Frank-Rainer Grahl (:frg)]

No need for further testing. I have a url which crashes reliably now after I fixed my error. 

Just didn't have time to look into it further. We are currently not using the openner in tabbrowser.xml. I either need to port the whole logic or a simple fix. Undecided yet. Might take some time until its fixed 

FRG

Comment 34

[Nika Layzell [:nika] (ni? for response)]

This is the patch which I used to fix android before the addition of the noopener flag (which was simply implemented by making adding that parameter conditional on the flag not being set). https://bug1303196.bmoattachments.org/attachment.cgi?id=8803039

I imagine that implementing this for seamonkey would be similarity simple.

For example, from my quick look I imagine you'll want to pass the value into here:
https://dxr.mozilla.org/seamonkey/source/browser/base/content/browser.js#4352
And into addTab:
https://dxr.mozilla.org/seamonkey/source/browser/base/content/tabbrowser.xml#1076-1077
And then you probably want to call `presetOpenerWindow(opener)` on the browser before it is added to the notificationbox here:
https://dxr.mozilla.org/seamonkey/source/browser/base/content/tabbrowser.xml#1207

I would perform the check against the noopener flag within loaduri, and simply not pass the opener parameter in if it is set.

Comment 35

[Frank-Rainer Grahl (:frg)]

Michael,

thanks for the heads up. Started yesterday with the patch but ran out of time. Will have to wait till the weekend. SeaMonkey does use the params a little differently so I need to make sure that I don't break anything. Identified the same places as you. Weren't sure about the presetOpenerWindow. Thanks for pointing this out.

FRG

Comment 36

[Tony Mechelynck [:tonymec]]

2.49 racking flags have come back. :-)

Comment 37

[Frank-Rainer Grahl (:frg)]

Attachment: 1316104-presetOpenerWindow.patch

Michael,

seems to get rid of the crash for me and I see no errors or fallout in the log. Do you think that is all which is needed? 

userContextId is unused for now but we need this soon I think so I put it in too.

Comment 38

[Nika Layzell [:nika] (ni? for response)]

Comment on attachment 8812283 [details] [diff] [review]
1316104-presetOpenerWindow.patch

Review of attachment 8812283 [details] [diff] [review]:
-----------------------------------------------------------------

Yup, that looks like it should do it from my quick reading :)

Comment 39

[Frank-Rainer Grahl (:frg)]

Comment on attachment 8812283 [details] [diff] [review]
1316104-presetOpenerWindow.patch

Michael thanks for the help here. Much appreciated.

Comment 40

[Rainer Bielefeld]

No longer reproducible with Server-Installation of  unofficial (by FRG) en-US SeaMonkey 2.49a2  (NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 Build 20161118170316  (Default Classic Theme) on German WIN7 64bit

Comment 41

[Philip Chee]

Comment on attachment 8812283 [details] [diff] [review]
1316104-presetOpenerWindow.patch

This fixes the crash.

We probably need to file follow-up bugs to audit all the places where we need to insert userContextId.
e.g.
[1] cookies Bug 1199466 Bug 1244795
[2]session history
[3] function loadURI()
https://hg.mozilla.org/mozilla-central/rev/a45cfe898352
Bug 1284395
[4] function openLinkIn() function openUILinkIn()

Comment 42

[Jorg K (CEST = GMT+2)]

What do we need to do in Thunderbird? There we currently have:
https://dxr.mozilla.org/comm-central/rev/b11789455e43844c9023262ddc34b992db99b082/mail/base/content/mailWindow.js#639

Comment 43

[Susanne Jaeger]

crashes occur in (official) Seamonkey Aurora Builds 

User agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49a2
Build identifier: 20161121013001

Workaround: changing Browser.link.open newwindow from 3 to 1 enables me to work again. Manually opening Link in new Tab or Window via context menu doesn't provoke crash.

Comment 44

[Frank-Rainer Grahl (:frg)]

Comment on attachment 8812283 [details] [diff] [review]
1316104-presetOpenerWindow.patch

[Approval Request Comment]
Regression caused by (bug #): 1303196
User impact if declined: Seamonkey crashes
Testing completed (on m-c, etc.): c-a and c-c
Risk to taking this patch (and alternatives if risky): non broken already
String changes made by this patch: -

Comment 45

[Tony Mechelynck [:tonymec]]

(In reply to Jorg K (GMT+1) from comment #42)
> What do we need to do in Thunderbird? There we currently have:
> https://dxr.mozilla.org/comm-central/rev/
> b11789455e43844c9023262ddc34b992db99b082/mail/base/content/mailWindow.js#639

FWIW, searching Socorro for crashes on this signature in the latest month finds 110 results, among which (sorting Z-A by Product) exactly zero for Thunderbird. OTOH, both SeaMonkey and Firefox are present.

Comment 46

[Frank-Rainer Grahl (:frg)]

Jorg,

as far as I see it mailwindow.js just needs to transfer the opener to \mail\base\content\tabmail.xml

Here: let newTab = tabmail.openTab(

openTab then just needs to set the opener with presetOpenerWindow like in our tabbrowser.xml code. Should be even less param checking involved compared to SeaMonkey.

>> exactly zero for Thunderbird

Tony I think this can only be reproduced installing an extension. Normal TB code doesn't use it. Not a web browser.

Comment 47

[Jorg K (CEST = GMT+2)]

FRG, would you care to give us a patch (please, please, ...), you seem to know more about it and I'd just hate to get it wrong.

Comment 48

[Philip Chee]

Comment on attachment 8812283 [details] [diff] [review]
1316104-presetOpenerWindow.patch

a=me for comm-aurora

Comment 49

[Frank-Rainer Grahl (:frg)]

Should hopefully be gone in tomorrows 2.49a2 builds:

https://hg.mozilla.org/comm-central/rev/4df935f993b2e7dac566661b712ba4d915b0c1d0
https://hg.mozilla.org/releases/comm-aurora/rev/fb1299a1bc6056dabdfc25cbca043562f8b94691

Jorg, even if it looks so I am not the expert in this. Will look at it Saturday at the latest. Please remind me if you do not hear back.

Comment 50

[Frank-Rainer Grahl (:frg)]

reminder for follow up bugs