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

RESOLVED FIXED in seamonkey2.50
(NeedInfo from)

Status

SeaMonkey
General
--
critical
RESOLVED FIXED
9 months ago
9 months ago

People

(Reporter: Rainer Bielefeld, Assigned: frg, NeedInfo)

Tracking

(Blocks: 1 bug, {crash, topcrash})

SeaMonkey 2.49 Branch
seamonkey2.50
Unspecified
Windows 7
crash, topcrash
Dependency tree / graph

SeaMonkey Tracking Flags

(seamonkey2.48 unaffected, seamonkey2.49esr fixed, seamonkey2.50 fixed)

Details

(Whiteboard: [easyconfirm], crash signature, URL)

User Story

Workaround:
===========
In preference ˋEdit → Preferences → Browser → Link Behavior – Link open behaviorˊ select an alternative to “… A new tab in the current window”

Developers: See also comment #20 (Summary of findings)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

9 months ago
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
(Reporter)

Updated

9 months ago
OS: Unspecified → Windows 7
(Reporter)

Comment 1

9 months ago
MOZ_CRASH Reason MOZ_RELEASE_ASSERT(!contentOpener || !mTabGroup || mTabGroup == Cast(contentOpener)->mTabGroup)
Crash Reason 	EXCEPTION_BREAKPOINT
Summary: CRASH when click particular link on particular WEB-page → CRASH (MOZ_RELEASE_ASSERT) when click particular link on particular WEB-page
(Reporter)

Comment 2

9 months ago
It seems that any link on that search result page will CRASH
Severity: normal → major
(Reporter)

Comment 3

9 months ago
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
(Assignee)

Comment 4

9 months ago
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.
Status: UNCONFIRMED → NEW
Depends on: 1303196
Ever confirmed: true
Flags: needinfo?(philip.chee)
(Assignee)

Comment 5

9 months ago
Likely caused by this one:

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

Comment 6

9 months ago
Looks like TabGroup assert crash.
Flags: needinfo?(michael)
(Assignee)

Comment 7

9 months ago
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.
Assignee: nobody → frgrahl
Status: NEW → ASSIGNED
Flags: needinfo?(philip.chee)
Attachment #8809081 - Flags: review?(philip.chee)
(Assignee)

Comment 8

9 months ago
Thunderbird is likely also affected:

mail/base/content/mailWindow Line 554 uses the same code as Firefox.
(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.
Flags: needinfo?(michael)

Comment 10

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

r=me a=me if tree needs APPROVAL
Attachment #8809081 - Flags: review?(philip.chee) → review+

Updated

9 months ago
Blocks: 1316389
(Assignee)

Comment 11

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

Leaving open to look into the other needed changes.
(Assignee)

Updated

9 months ago
status-seamonkey2.48: --- → unaffected
status-seamonkey2.49esr: --- → fixed
Keywords: leave-open
(Reporter)

Comment 12

9 months ago
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.
Severity: major → critical
Summary: CRASH (MOZ_RELEASE_ASSERT) when click particular link on particular WEB-page → CRASH (MOZ_RELEASE_ASSERT) when click link which opens link target in new TAB
(Reporter)

Comment 13

9 months ago
e) The crash is related to a particular preference, see workaround 
   in user_story_header
User Story: (updated)

Updated

9 months ago
Blocks: 1316561
(Reporter)

Updated

9 months ago
See Also: → bug 1316950
Duplicate of this bug: 1316950
[@ 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")
Keywords: topcrash
Crash Signature: bp-3f7c56db-2b0d-4837-81cc-a712f2161108 → [@ nsGlobalWindow::SetOpenerWindow]
Summary: CRASH (MOZ_RELEASE_ASSERT) when click link which opens link target in new TAB → CRASH [@ nsGlobalWindow::SetOpenerWindow] (with MOZ_RELEASE_ASSERT) when click link which opens link target in new TAB
See Also: bug 1316950
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"
(Assignee)

Comment 17

9 months ago
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
status-seamonkey2.49esr: fixed → affected
(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.
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).
Flags: needinfo?(frgrahl)
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
User Story: (updated)
(Assignee)

Comment 21

9 months ago
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
Flags: needinfo?(frgrahl)
(Assignee)

Comment 22

9 months ago
Created attachment 8810417 [details] [diff] [review]
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

9 months ago
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

9 months ago
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

9 months ago
>>  nsBrowserAccess.prototype = {
>>    openURI: function openURI(aURI, aOpener, aWhere, aFlags) {
>> +    var isExternal = !!(aFlags & Components.interfaces.nsIBrowserDOMWindow.OPEN_EXTERNAL);
> 
> I landed "Components.interfaces. ... ;-)
See Comment 24
Flags: needinfo?(jorgk)
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

9 months ago
(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
Flags: needinfo?(jorgk)
(Assignee)

Comment 28

9 months ago
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

9 months ago
(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.
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 ;-)
Whiteboard: [easyconfirm] → [easyconfirm] [seamonkey-2.49-affected]
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.
(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.
(Assignee)

Comment 33

9 months ago
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
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.
(Assignee)

Comment 35

9 months ago
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
(Assignee)

Updated

9 months ago
status-seamonkey2.50: --- → affected
(Assignee)

Updated

9 months ago
Blocks: 1313304
2.49 racking flags have come back. :-)
Whiteboard: [easyconfirm] [seamonkey-2.49-affected] → [easyconfirm]
(Assignee)

Comment 37

9 months ago
Created attachment 8812283 [details] [diff] [review]
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.
Attachment #8810417 - Attachment is obsolete: true
Attachment #8812283 - Flags: feedback?(michael)
(Reporter)

Updated

9 months ago
See Also: → bug 1318596
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 :)
Attachment #8812283 - Flags: feedback?(michael) → feedback+
(Assignee)

Comment 39

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

Michael thanks for the help here. Much appreciated.
Attachment #8812283 - Flags: review?(philip.chee)
(Reporter)

Comment 40

9 months ago
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
(Assignee)

Updated

9 months ago
Blocks: 1319091

Comment 41

9 months ago
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()
Attachment #8812283 - Flags: review?(philip.chee) → review+

Comment 42

9 months ago
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

9 months ago
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.
(Assignee)

Comment 44

9 months ago
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: -
Attachment #8812283 - Flags: approval-comm-aurora?
(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.
(Assignee)

Comment 46

9 months ago
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

9 months ago
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

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

a=me for comm-aurora
Attachment #8812283 - Flags: approval-comm-aurora? → approval-comm-aurora+
(Assignee)

Comment 49

9 months ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 months ago
status-seamonkey2.49esr: affected → fixed
status-seamonkey2.50: affected → fixed
Keywords: leave-open
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.50
(Assignee)

Comment 50

9 months ago
reminder for follow up bugs
Flags: needinfo?(frgrahl)

Updated

9 months ago
Duplicate of this bug: 1318596
You need to log in before you can comment on or make changes to this bug.