User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20171114221957 Steps to reproduce: Set window.open to be called when a value is set to true, which it is set to after 4000ms and i made numerous asynchronous calls to fetch a website in which it's catch block contains the same check made by the window.open block but instead it sets window.location.pathname to another site. TO VIEW THE CODE IN ACTION, Unpack the attached zip file and open index.html in firefox but it will be better to serve the page from a server. Actual results: The page alerts leaving after 4000ms and when you press OK it takes you to another.html Expected results: When you click OK it is supposed to open site2.html because that was the url window.open was told to go to

Here's the index.html file from the zip. There are two other files, but they are just dummy HTML files. As I said in the attachment description, you'd need the other files to actually reproduce this. I am just attaching this here to make it easier for people to look at it.

I'm not sure if this is expected or not, but seems like a DOM-related issue in either case.

(In reply to Andrew McCreight [:mccr8] from comment #1) > Created attachment 8994349 [details] > index.html from zip, WON'T WORK STANDALONE > > Here's the index.html file from the zip. There are two other files, but they > are just dummy HTML files. As I said in the attachment description, you'd > need the other files to actually reproduce this. I am just attaching this > here to make it easier for people to look at it. Yes, sorry i forgot to mention that. site2.html is the intended url to be redirected to but it is actually redirected to another.html after window.open is called

Nika, please spend a bit of time investigating here. Thank you!

This is simply caused by Firefox spinning a nested event loop within the alert. This is known behaviour which, while unfortunate, would be very difficult to avoid currently. I think this is probably specifically a dup of bug 801304.