found via bughunter and reproduced on latest m-c tinderbox windows debug build. Steps to reproduce: -> Load http://www.cebbank.com/ ---> Assertion Assertion failure: aPrincipalToInherit || (!aTriggeringPrincipal || aTriggeringPrincipal->GetIsNullPrincipal() || (aFlags & INTERNAL_LOAD_FLAGS_INHERIT_PRINCIPAL)), at c:/builds/moz2_slave/m-cen-w32-d-000000000000000000/build/src/docshell/base/nsDocShell.cpp:9753

I am on it, will provide some debug information a little later tonight.

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #1) > I am on it, will provide some debug information a little later tonight. Seems Windows specific, can't reproduce on Linux.

Kamil, I don't have a windows machine handy, any chance you could provide a more detailed stacktrace? All you would have to do is: a) Get a Nightly on Windows b) Navigate to http://www.cebbank.com/ c) Paste stacktrace here Thanks!

Chris, I tried loading the website you mentioned using several different Win machines but couldn't reproduce the issue. Is there anything else I can try? Tested using the following builds: * fx52.0a1, buildId: 20161017030209, changeset: 94b0fddf96b4 ** https://archive.mozilla.org/pub/firefox/nightly/2016/10/2016-10-17-03-02-09-mozilla-central/ * fx52.0a1, buildId: 20161017113943, changeset: 7c8216f48c38 central/tip Tested using the following platforms: * Win 10 x64 - couldn't reproduce * Win 8.1 x64 VM - couldn't reproduce * Win 7 x64 VM - couldn't reproduce Test Cases Used: - Opened the website several times using both e10s and non-e10s - Opened the website several times using PB mode - allowed pop-ups from http://www.cebbank.com/ (nightly was blocking the pop-up by default) - restored the browser several times with about 15 instances of http://www.cebbank.com/ opened - opened several links using "Open Link in New Tab" via the right context menu - navigated through portions of the website I also tried reproducing the issue using the following asan build under Ubuntu 16.04: * https://index.taskcluster.net/v1/task/gecko.v2.mozilla-central.latest.firefox.linux64-asan-opt/artifacts/public/build/target.tar.bz2

(In reply to Kamil Jozwiak [:kjozwiak] from comment #4) > Chris, I tried loading the website you mentioned using several different Win > machines but couldn't reproduce the issue. Is there anything else I can try? Thanks Kamil for testing. @Carsten, can you still repro the problem? Any chance you could provide a detailed stakctrace?

> Seems Windows specific, can't reproduce on Linux. I can reproduce this in my local Linux64 debug build. I suspect it's a (very) recent regression -- last few days or so.

BTW, it happens on startup for me, while restoring the (dozen or so) tabs.

can't reproduce anymore, but from mats comment this seems to be a regression

Neither can I, fwiw.

Still crashed on startup on today's tip <http://hg.mozilla.org/mozilla-central/rev/c845bfd0accb>. The stack is the same as Mats.

I guess it's caused by restoring https sessions. There was a tab connected to https://www.netflix.com/browse .

(In reply to Hiroyuki Ikezoe (:hiro) from comment #12) > I guess it's caused by restoring https sessions. There was a tab connected > to https://www.netflix.com/browse. I tried seeing if I could reproduce the crash using the above case under Windows/Ubuntu but didn't have any luck :/ :hiro, can you reproduce the crash consistently when restoring https sessions or is it intermittent? Platforms/Builds Used: * Win 10 Pro x64 - couldn't reproduce ** build used: fx52.0a1, buildId: 20161025004513, changeset: c845bfd0accb central/tip * Ubuntu 16.04.1 LTS x64 VM - couldn't reproduce ** build used: fx52.0a1, buildId: 20161025102719, changeset: c6ccd71126ff central/tip Test Cases Used: * login into netflix (https://www.netflix.com/browse) * restore the tab via the "restore previous session" under about:home * restore the tab using "Show my windows and tabs from last time" under about:preferences#general

(In reply to Kamil Jozwiak [:kjozwiak] from comment #13) > (In reply to Hiroyuki Ikezoe (:hiro) from comment #12) > > I guess it's caused by restoring https sessions. There was a tab connected > > to https://www.netflix.com/browse. > > I tried seeing if I could reproduce the crash using the above case under > Windows/Ubuntu but didn't have any luck :/ > > :hiro, can you reproduce the crash consistently when restoring https > sessions or is it intermittent? Yes, it's intermittent. But once it happened, crashes repeatedly until I remove the tab by stable firefox (49). One more note that the profile which I used yesterday is a profile for testing I've been using. I've never logged-in netflix with this profile, and had never seen this crash until I logged in netflix.

(In reply to Hiroyuki Ikezoe (:hiro) from comment #14) > One more note that the profile which I used yesterday is a profile for > testing I've been using. I've never logged-in netflix with this profile, > and had never seen this crash until I logged in netflix. I *had* never logged-in netflix and had never seen the crash.

FWIW, most likely Bug 1308889 will remove that assertion. Let's wait what we decide within Bug 1308889 and then I'll follow up in this bug.

P2, mirroring priority of bug 1308889

The assertion in question was added by Bug 1303943, which landed in FF52. Bug 1308889 removed that assertion (also within FF52). Hence marking this bug as resolved.