931987 - Multiple onbeforeunload prompts from iframes should be suppressed.

Status: RESOLVED DUPLICATE of bug 636374

(Toolkit :: General, defect)

Description

[ross9885]

http://rcmp.gc.ca.id322741945-7168387823.v7743[ replace with ".com" if you dare ] creates an endless series of alerts and confirmations. This site is a good example of a worst-case scenario, because it impersonates an RCMP (Canadian police) site and extorts a small fine for breaking a vague list of terrible felonies. There are similar versions of the site for the FBI.

Nothing in the UI will get you out of there. When I killed the Firefox process from the terminal and then restarted, Firefox loaded the site again!

Solutions:

- A global Javascript kill switch. Pause all scripts in the whole Firefox process so that tabs can be closed, then toggle the switch to turn scripts back on. Plugins should probably also be paused.

- Do not reopen tabs from crashed processes by default. If Firefox crashes or gets killed, there is usually a good reason for that, and caution is warranted when restarting. The kill command exists for a reason.

- Add a "No more modal dialogs" button to all modal dialogs.

Similar but outdated reports:

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

If this has been fixed in more recent versions of Firefox, then the fix should be backported to older major versions because it is a security issue and because users who install Firefox through a package manager on Ubuntu get the version 24 branch.

Comment 1

[ross9885]

Edit:

http://rcmp.gc.ca.id322741945-7168387823.v7743[ APPEND ".com" if you dare ] to visit the site. Do not visit the site unless you are confident about the security of your browser and it's plugins. You will have to kill the process to leave.

Comment 2

[Justin Dolske [:Dolske]]

(Note that visiting the URL doesn't prompt immediately, you have to try to navigate to a different page.)

Hmm. I see 2 problems.

1) The first prompt it show isn't coming up as tab-modal. I see nsDocumentViewer::PermitUnload() in the callstack when it's up, so presumably the page's onbeforeunload handler is triggering this. Bug 391834 was supposed to fix that, but I've seen so other work go by recently too. (Tim, didn't you just patch something like this?)

2) If I click the "Leave Page" button in our onbeforeunload prompt, it just comes up again.

Comment 3

[Justin Dolske [:Dolske]]

Attachment: Page source

I see a boatload of <iframe onbeforeunload="">, that's probably causing the looping.

The first prompt seems to be plain and simple, so not sure why we seem to miss blocking it entirely:

window.onbeforeunload = function(env){
		var str = 'YОUR'+' BRОW'+'SЕR '+'HАS BЕЕ'+'N LОC'+'KЕD. [...];
		alert(str);
		return str;
	}

Comment 4

[Justin Dolske [:Dolske]]

Ah. That _was_ just fixed in bug 856977. My Nightly was a month old, since I'm using UX nightly... After updating the page no longer shows an initial alert(). Looking at the looping.

Comment 5

[Justin Dolske [:Dolske]]

Attachment: 3-prompt testcase

Conformed that if I (1) disable JS, (2) nuke all the iframes with the devtools, (3) reenable JS, and finally (4) leave the page, that I get no further prompts.

Attaching a simpler non-malicious testcase that reproduces the problem.

Comment 6

[ross9885]

How did you disable JS? I thought that feature was removed. I looked around for it in the dev tools, but I didn't find it.

Comment 7

[Justin Dolske [:Dolske]]

Hmm, this seems a little tricky to fix. Ideally (*handwavy*) we'd just drop in an AreDialogsEnabled() check and DisableDialogs() when the user first clicks a Leave. Except that condition already seems to end up true here. And I could imagine a hypothetical page that runs some app in an iframe, which in turn legitimately uses onbeforeunload to guard against dataloss...  Clicking Leave Page in that case shouldn't cancel future dialogs from the iframe, but I also can't get too worked up about it.

Maybe this should just be treated as a special case when closing a top-level document (tab). Roughly:

* When closing, if window == window.top, set window.top.topDocIsClosing
* In PermitUnload(), if the user clicks "Leave Page" and window.top.topDocIsClosing is set, set a new window.top.noMoreUnloadPrompts. If user clicks Stay On Page, clear topDocIsClosing.
* Add a check to skip the onbeforeunload prompt if window.top.noMoreUnloadPrompts is set.

That would make prompts work as they currently do, but fairly robustly (I hope ;) guard against ever getting multiple prompts when you're trying to close the tab.

Having this prompt trigger via iframes is kind of sadmaking, but I suspect that ship has sailed.

Comment 8

[Justin Dolske [:Dolske]]

(In reply to ross9885 from comment #6)
> How did you disable JS? I thought that feature was removed.

The checkbox in the UI was, but it's still available as javascript.enabled from about:config.

Comment 9

[ross9885]

Thanks for the tip!

As an outsider, I have to say that this all sounds too clever to be reliable. The more complicated the rules get around dialogs, the more likely that loopholes will be created and developers who rely on dialogs will be confused. 

In the end, the user should be in control, and there are simple ways to give the user more control. A big red JS kill switch with a keyboard shortcut. My friends and family already hit the hardware reset when they get too frustrated or scared with broken or malicious pages, that should be considered in the UX design.