User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 Build ID: 20160604131506 Steps to reproduce: 1 - From my app, launched a new window (tab) 2 - Tore off the tab (creates new window) Actual results: Crash https://crash-stats.mozilla.com/report/index/4c2aba99-3fc9-4593-939a-b29f42160627

Additional: Background, see https://bugzilla.mozilla.org/show_bug.cgi?id=1280091#c25 Also: https://bugzilla.mozilla.org/show_bug.cgi?id=1271792#c30 / 31 As per Mike Taylor's request, I filed this report. I went ahead and did a mozregression but I could not make it fail. Yet, in latest Nightly, it's 100% repeatable. Also: 1 - Does NOT occur if e10s is DISABLED 2 - Both windows maintain a handle to each other for postmessage traffic.

Is this a general crash or Container Tabs specific? From the STR it seems to be a general issue.

(In reply to Tanvi Vyas[:tanvi] from comment #2) > Is this a general crash or Container Tabs specific? From the STR it seems > to be a general issue. I don't think the STR uses container tabs, but it involves platform code paths that were recently changed to support container tabs, so I was thinking it was possible there is a connection. Anyway, there might be a better component, I wasn't sure.

What is a "Container Tab"?

Just accepted Nightly 50.0a1 20160628030238 from nightly channel - same bug. (It would be helpful if users could scrape that user-unfriendly number right off the dialog box. If it's so hugely important to print in bold font, why not make it accessible?) What I don't understand is why mozregression can't find the regression. Can someone explain, please?

(In reply to Codacoder from comment #4) > What is a "Container Tab"? Containers is an experimental feature to allow users to separate browsing contexts. See the blog post here: https://blog.mozilla.org/tanvi/2016/06/16/contextual-identities-on-the-web/

(In reply to Codacoder from comment #0) > User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 > Firefox/47.0 > Build ID: 20160604131506 > > Steps to reproduce: > > 1 - From my app, launched a new window (tab) > > 2 - Tore off the tab (creates new window) Is this Windows 10 specific? I'm having trouble reproducing this but Im on a window 7 VM. I'm not sure what you mean by "from my app...". What I am doing is: 1. Open a webpage 2. This webpage calls window.open('http://mozilla.com') to create new window (new tab) 3. Tearing this tab off the bar, so that it creates a new OS window Is that the correct STR?

(In reply to Paul Theriault [:pauljt] from comment #7) > (In reply to Codacoder from comment #0) > > User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 > > Firefox/47.0 > > Build ID: 20160604131506 > > > > Steps to reproduce: > > > > 1 - From my app, launched a new window (tab) > > > > 2 - Tore off the tab (creates new window) > > Is this Windows 10 specific? I'm having trouble reproducing this but Im on a > window 7 VM. I'm not sure what you mean by "from my app...". What I am doing > is: > > 1. Open a webpage > 2. This webpage calls window.open('http://mozilla.com') to create new window > (new tab) > 3. Tearing this tab off the bar, so that it creates a new OS window > > Is that the correct STR? @Paul, Pretty much the same but with added info from Comment 1. All I can add is: - it's 100% repeatable, with e10s enabled - mozregression cannot find it (huh?) "my app" === the humongous asp.net app I work on. In this scenario, a web page, running a DSL written in JS, is being debugged by another web page running a custom debugger (communicating via postmessage). This works "everywhere" except in the current Nightly since about ~26th June. If you want to witness it, I can show you via a gotomeeting session.

(In reply to Paul Theriault [:pauljt] from comment #7) > Is this Windows 10 specific? Win 7.

Not sure if these are helpful - same STR, different results. https://crash-stats.mozilla.com/report/index/2f12d595-f989-4c93-ab6d-ef6312160411 https://crash-stats.mozilla.com/report/index/5835a96a-2a17-4499-86d2-8f33f2160623 https://crash-stats.mozilla.com/report/index/4b103cd1-51ce-4853-bbe1-013242160411 https://crash-stats.mozilla.com/report/index/31fd35c2-d510-4079-9246-f78b32160623

Kamil, can you take a look at this bug when you have sometime? Thanks!

I've been trying to reproduce this on both the release/debug versions of m-c for sometime now without any luck. I'll keep trying but hopefully Codacoder can provide us with a test case/URL. > Is this Windows 10 specific? From the looks of the crash reports [1], most of the crashes are happening on Win 7, Win 8.1 and Win 10. There's some crashes on OSX/Linux, but the majority are on Windows. It's also happening on aurora. Codacoder, can you still reproduce this reliably using your previous test case from comment #0? Would you be able to provide a test case or a link to a URL if it's still reproducible on your end? [1] https://crash-stats.mozilla.com/search/?signature=~mozilla%3A%3Adom%3A%3ATabChild%3A%3ARecvSwappedWithOtherRemoteLoader&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

(In reply to Kamil Jozwiak [:kjozwiak] from comment #12) > I've been trying to reproduce this on both the release/debug versions of m-c > for sometime now without any luck. I'll keep trying but hopefully Codacoder > can provide us with a test case/URL. > > > Is this Windows 10 specific? > > From the looks of the crash reports [1], most of the crashes are happening > on Win 7, Win 8.1 and Win 10. There's some crashes on OSX/Linux, but the > majority are on Windows. It's also happening on aurora. Win7. > Codacoder, can you still reproduce this reliably using your previous test > case from comment #0? With e10s enabled, 100%, e.g., https://crash-stats.mozilla.com/report/index/4ef79469-2b93-4b2b-a46d-111b12160718 > Would you be able to provide a test case or a link to > a URL if it's still reproducible on your end? > No, not possible. I can show you my desktop over gotomeeting. Let me know if you want me to set it up.

> No, not possible. I can show you my desktop over gotomeeting. I'm not sure how useful this would be, we would need to do some debugging on that machine. > What I don't understand is why mozregression can't find the regression Were you using the GUI version or the original command line tool? If you were originally using the GUI version, would you mind going through it once again but this time using the command line tool [1]? The GUI version is still in the early development stage so it might be why you're not finding a regression range. If you do install the command line tool, can you reproduce the issue using the latest version of nightly via "mozregression --launch 2016-07-19". If you end up reproducing the issue, you should be able to get a regression range. [1] http://mozilla.github.io/mozregression/install.html#mozregression

(In reply to Kamil Jozwiak [:kjozwiak] from comment #15) > > No, not possible. I can show you my desktop over gotomeeting. > > I'm not sure how useful this would be, we would need to do some debugging on > that machine. Well, the offer is there. I'm not a moz-dev, so agreed, usefulness might be limited. Other moz-devs have done so in the past. > > What I don't understand is why mozregression can't find the regression > Were you using the GUI version or the original command line tool? Yep. > If you > were originally using the GUI version, would you mind going through it once > again but this time using the command line tool [1]? I will.

(In reply to Codacoder from comment #16) > (In reply to Kamil Jozwiak [:kjozwiak] from comment #15) > > If you > > were originally using the GUI version, would you mind going through it once > > again but this time using the command line tool [1]? C:\Utils>mozregression --launch 2016-07-19 0:00.92 INFO: bits option not specified, using 64-bit builds. 0:03.85 ERROR: Unable to find build info for 2016-07-19

Codacoder, thanks for your report! I have some questions: * Does your app use ServiceWorkers? And in particular ServiceWorkerClient? * Does your app use popups or dialogs? * How is this new window opened? * Have you used Containers? Or this crash happens with a normal navigation?

Hmm I really don't know what to make of this. I can't find a bad build at all, yet, my current nightly fails 100%. I tried providing --good and --bad dates to mozregression but in each case, it aborted with "this should have been bad!" The only thing that's left for me to try is a new, empty, clean, virgin profile. And that works. What could be in a profile that causes this bug? Keep in mind, this profile has no addons/extensions applied and 99% of the use is for developing my asp.net app. It was created while helping you guys with Bug 1280091 - so it's very "young". And yes, e10s is enabled.

(In reply to Andrea Marchesini (:baku) from comment #18) > Codacoder, thanks for your report! > > I have some questions: > * Does your app use ServiceWorkers? And in particular ServiceWorkerClient? No but it does use PostMessage to communicate across windows/tabs A and B. > * Does your app use popups or dialogs? No (they're all "divs") > * How is this new window opened? this.dbgeeWindow = window.open(url, winName + $WE.$page.activePageName, "", true); > * Have you used Containers? Or this crash happens with a normal navigation? I don't know what containers are. What is "normal navigation"? Indeed, what is "abnormal" navigation?

> C:\Utils>mozregression --launch 2016-07-19 > 0:00.92 INFO: bits option not specified, using 64-bit builds. > 0:03.85 ERROR: Unable to find build info for 2016-07-19 It looks like the x64 build of nightly wasn't added into the folder today. Could you try the same thing but with yesterdays build? The following worked: * -> mozregression --launch 2016-07-18 If you can't reproduce the issue with the x64 builds, try using the x86 builds. You can tell mozregression to use x86 builds via: * -> mozregression --write-config If you do end up reproducing the issue with a build that you've downloaded via mozregression, try getting the regression range via: * -> mozregression --good 2016-06-01 --bad 2016-07-18 You can play around with the --good date until you've find a version of nightly that works (if you end up reproducing the problem)

(In reply to Kamil Jozwiak [:kjozwiak] from comment #21) > If you do end up reproducing the issue with a build that you've downloaded > via mozregression, try getting the regression range via: > * -> mozregression --good 2016-06-01 --bad 2016-07-18 > > You can play around with the --good date until you've find a version of > nightly that works (if you end up reproducing the problem) That's exactly what I did, Kamil. And if I wasn't clear, a NEW profiles clears the bug completely (see Comment 19)

Okay, I have the conditions pretty much nailed 1 - Any nightly 2 - In options > General check Enable multi-process Nightly 3 - In options > Privacy > History, set "Never remember history" 4 - then follow original STR If I set history to Remember history, NO crash. Hope this helps you guys nail it.

Current Developer Edition affected too. 49.0a2 (2016-07-19)

Thanks a lot! I think I found the issue. The patch has been uploaded in another bug. I mark this bug as duplicate. Let's move the discussion to bug 1280105.