Open Bug 1315677 Opened 8 years ago Updated 3 months ago

Using opener.alert() to open an alert in a background tab blocks JS execution in the *current* tab and produces a confusing user experience

Categories

(Core :: DOM: Core & HTML, defect, P2)

Product:
Core
Component:
DOM: Core & HTML
Version:
49 Branch
Type:
defect

Tracking

()

People

(Reporter: jm.acuna73, Unassigned)

References

Details

(Keywords: csectype-dos, sec-low)

Attachments

(1 file, 1 obsolete file)

ice_video_20161107-150943.webm
8.06 MB, video/webm
Details 
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36

Steps to reproduce:

1- creates a local html file:

<html>
<head><title>Page Locking</title></head>
<body>

<a href="https://www.mozilla.org/en-US/firefox/new" onclick="
	var x = top.open(this.href,window,'');
	setTimeout(function(){
		x.document.body.outerHTML += '\
		<iframe src=http://www.adslzone.net/app/uploads/2016/02/mozilla-firefox-evitar-rastreo.jpg onload=parent.top.opener.alert(\'blocking\')\
			style=position:fixed;top:0;left:0;width:100%;height:100%;border:0></iframe>';
	}, 0);
	return false;">
	Page Locking
</a>

2- run in mozilla firefox


Actual results:

the implementation of the new page is blocked


Expected results:

should block the first tab not allowing open a new tab until the modal dialog will not close (as in google chrome)
Group: firefox-core-security
Keywords: csectype-dos, sec-low
See Also: → 1313916, 332195
Summary: you can block the execution of any web page → Using opener.alert() to open an alert in a background tab blocks JS execution in the *current* tab and produces a confusing user experience
See Also: → 1316798
I can reproduce this issue on es-MX/ build 

Agente de usuario 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0

This issue is not reproducible for me on en-US build. I see same behavior on Chrome and Firefox(en-US).
Status: UNCONFIRMED → NEW
Component: Untriaged → DOM: Core & HTML
Ever confirmed: true
Product: Firefox → Core
:marcosc tried to reproduce on MacOS using Nightly, but want not able to get it to lock. Getting "Error: Permission denied to access property "document""

Is that above expected?
Flags: needinfo?(jm.acuna73)
Flags: needinfo?(jm.acuna73)
1- Tested on Firefox 50.1.0 and Firefox Developer Edition 52.0a2 (2016-12-19) (32-bit) for windows
2- To reproduce the case it is necessary to clear the browser cache

Demo: https://drive.google.com/file/d/0B5G3cbs08P16Nm14eUhzb2hCSDQ/view
I still cannot reproduce this issue with the example code on comment 0 due to "Error: Permission denied to access property "document""  However, I did see this issue if I modify the "iframe src", that is, let it meet same-origin-policy, for example "<iframe src=https://www.mozilla.org/en-US/privacy/firefox/"

Hi Catalin,
I am flagging on you since you are looking at bug 1316798 which looks somewhat related with you, and I am guessing you might find this interesting to look into as well. :)
Flags: needinfo?(catalin.badea392)
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #4)
> I still cannot reproduce this issue with the example code on comment 0 due
> to "Error: Permission denied to access property "document""  However, I did
> see this issue if I modify the "iframe src", that is, let it meet
> same-origin-policy, for example "<iframe
> src=https://www.mozilla.org/en-US/privacy/firefox/"
> 
> Hi Catalin,
> I am flagging on you since you are looking at bug 1316798 which looks
> somewhat related with you, 
                   ^^^^^^^^^  typo: I meant, somewhat related with this bug :)

> and I am guessing you might find this interesting
> to look into as well. :)
I managed to reproduce this on developer edition 52.0a2 (2016-12-19) 64-bit macOS. For nightly this happens only for same origin urls. However, I don't see JS main loop execution being blocked in the new tab.

One thing that's interesting, if the alert happens before the new tab fires the 'load' event, it will block it indefinitely.

I'll investigate this further.
Assignee: nobody → catalin.badea392
Flags: needinfo?(catalin.badea392)
Thanks Catalin!
Priority: -- → P2
Assignee: catalin.badea392 → nobody
Severity: normal → S3
Attachment #9387082 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: