Nikolay Atanasov Reporter
	Description • 10 years ago

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.102 Safari/537.36

Steps to reproduce:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0

<a href="http://localhost/?BUG" onclick="return confirm('you sure?')">TEST</a>

1. Open a html file with the contents above. 
2. Open a blank tab.
3. Click the link TEST in order to open the modal window.
4. Close the tab while the modal is open. 
5. Check access log to see that the request was made, as if the link was clicked.


Actual results:

A HTTP request was made. 


Expected results:

A HTTP request should not have been made

	Alice0775 White
	Comment 1 • 10 years ago

Confirmed in Nightly34.0a1 and Firefox24 as well, Repeat STR twice, I got the following access log.


http://localhost/?BUG

GET /?BUG HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

	Boris Zbarsky [:bzbarsky]
	Comment 2 • 10 years ago

Great fun.  The problem is that the click processing blocks on the confirm returning, which happens after the tab is closed; then the click processing presses on.  Olli, can we check for the "tab is closed" case at that point?

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 3 • 10 years ago

How is this different to calling <a>.click() at very late point of beforeunload/unload.

Though, tabmodal confirm should default to 'cancel', not to 'ok'.

	:Gijs (he/him)
	Comment 4 • 10 years ago

Boris and I briefly discussed this on IRC, and I suspect (but haven't verified) that this is because the prompt's abortPrompt code gets triggered and throws an exception. Now, the prompt service might be interested in that, and some of it chrome consumers might be especially - but nsGlobalWindow::Prompt and friends should probably swallow it and return the 'cancel' option from the prompt as a return value to the web page, instead of an exception - much like we silently swallow issues with setting location.href and friends.

	Alice0775 White
	Comment 5 • 10 years ago

In this Altered Test html, return false by [OK],  true by [Cancel].
However, same problem happens.

So, I think that
default [Cancel] (comment#3) --- not solve
return false from widget when exception occurred (comment#4) --- not solve

	:Gijs (he/him)
	Comment 6 • 10 years ago

What comment #4 proposes is roughly the following, which works in my testing, actually... Alice, am I missing something?

	Alice0775 White
	Comment 7 • 10 years ago

Disabling Bug 59314 solves every thing.

IE11 and Chrome37 are using window modal dialog insted of tab modal one!
So, I think it is time to back out Bug 59314!

	Alice0775 White
	Comment 8 • 10 years ago

(In reply to :Gijs Kruitbosch from comment #6)
> Created attachment 8482866 [details]
> Alternative test v2
> 
> What comment #4 proposes is roughly the following, which works in my
> testing, actually... Alice, am I missing something?

Okay

	Boris Zbarsky [:bzbarsky]
	Comment 9 • 10 years ago

Er, no, comment 4 can't do what comment 6 suggests.  What I was talking about on irc is just making confirm() return false when canceled...  but yes, that would not address attachment 8482857 [details].

However, do we _care_ about addressing it?  See comment 3.

	Boris Zbarsky [:bzbarsky]
	Comment 10 • 10 years ago

And to be clear, the UX of using window-modal dialogs sucks, and we should not go back to it.  The fact that other browsers have the sucky UX doesn't mean we have to make ours worse.

	Firefox Bug Husbandry Bot
	Comment 11 • 6 years ago

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.