Closed Bug 685828 Opened 13 years ago Closed 6 years ago

while(true) {window.open(...);} hangs Firefox

Categories

(Firefox :: Security, defect, P3)

Product:
Firefox
Component:
Security
Version:
6 Branch
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 65
Tracking Flags:
Tracking Status
firefox65 --- verified

People

(Reporter: kaisellgren, Assigned: johannh)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: csectype-dos, testcase, Whiteboard: [sg:dos])

Attachments

(1 file)

Bug 685828 - Limit displaying blocked popups in the front-end. r=Gijs,baku
(deleted), text/x-phabricator-request
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1 Steps to reproduce: I ran this script: while (true) {window.open('http://google.fi');} Actual results: Firefox crashed. Expected results: Firefox should pop up "Do you want to terminate the script?" and actually terminate it.
Group: core-security
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash, testcase
Whiteboard: [sg:dos]
I noticed an interesting thing. Firefox has this ad-block support. The right side handle allows you to enable specific pop-ups that were about to open. This list keeps getting bigger and bigger with each window.open() call so maybe the issue lies with that (the drop down getting enormous)?
Severity: normal → critical
Blocks: eviltraps
The Platform field says "Windows 7", but the problem occurs under Linux too. Actually, with Fvwm + manual window placement, this is worse, as this completely blocks the whole desktop UI.
Keywords: csectype-dos, csectype-oom
OS: Windows 7 → All
Hardware: x86_64 → All
An update I got yestaday has rendered another instance of this bug useless what would happen is if the window.open(string) is small it will just hang and you have to close it with taskman but if you increase the length of the string to let's say 10000 now open it and Firefox will hang then close with oom crash long and if you check it out in a debugger an addres of unk_xxxxxx gets over written with a section of the string you place in the ver and as of the update yestaday this no longer happens but the crash is happning in xul.dll unable to write 0x0 to invalid address 0x0000000
Depends on: 1269917
Triaging bugs at the moment and this one seems like an exact duplicate of Bug 676975. It also relies on the window.open() annoy mechanism.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Sorry, this is the right duplicate.
As mentioned in bug 1444752, I don't think this is a dupe. Bug 675574 is about opening infinite popups when being allowed to open (such as in event handling context), while this one is about the crash/hang/slowness (with e10s on) that results in blocking a large number of popups. I'd say bug 675574 is much worse, but this one seems easy to solve or at least easy to experiment with a solution for. My theory is that this gets fixed by throttling sending or receiving the DOMPopupBlocked event.
Severity: critical → normal
Status: RESOLVED → REOPENED
Keywords: crash, csectype-oom
Priority: -- → P3
Resolution: DUPLICATE → ---
Summary: while(true) {window.open(...);} crashes Firefox → while(true) {window.open(...);} hangs Firefox
Assignee: nobody → jhofmann
Status: REOPENED → ASSIGNED
Attachment #9023259 - Attachment description: Bug 685828 - Limit displaying blocked popups in the front-end. r=Gijs!,baku → Bug 685828 - Limit displaying blocked popups in the front-end. r=Gijs,baku
Pushed by jhofmann@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/74807b4c104a Limit displaying blocked popups in the front-end. r=Gijs
https://hg.mozilla.org/mozilla-central/rev/74807b4c104a
Status: ASSIGNED → RESOLVED
Closed: 7 years ago → 6 years ago
status-firefox65: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 65
Flags: qe-verify+

I managed to reproduce the crash on Firefox 9.0a1 (2011-09-03), under Windows 10x64.
The issue is not reproducible on Firefox 66.0a1 (2019-01-09), or on Firefox 65.0b9, under Windows 10x64 and under macOS 10.12.6.

On Ubuntu 18.04x64, after running the script from comment 0, the computer hangs, without the possibility of doing anything for closing Firefox or stopping the script (computer needs to be restarted).

Johann, should I open a separate bug for Ubuntu, or it's ok to reopen this one?

Flags: needinfo?(jhofmann)

(In reply to Mihai Boldan, QA [:mboldan] from comment #20)

I managed to reproduce the crash on Firefox 9.0a1 (2011-09-03), under Windows 10x64.
The issue is not reproducible on Firefox 66.0a1 (2019-01-09), or on Firefox 65.0b9, under Windows 10x64 and under macOS 10.12.6.

On Ubuntu 18.04x64, after running the script from comment 0, the computer hangs, without the possibility of doing anything for closing Firefox or stopping the script (computer needs to be restarted).

Johann, should I open a separate bug for Ubuntu, or it's ok to reopen this one?

I can't reproduce this on Ubuntu. How do you execute the script?

Flags: needinfo?(jhofmann) → needinfo?(mihai.boldan)

It seems that the issue is no longer reproducible on Ubuntu OS. I've tested it on Firefox 65.0b11, under Ubuntu 16.04x64 and under Ubuntu 18.04x64.
The script was run from the Web Console.
Since no crash or hangs were occurred, and bug 1519095 was logged for the wrong pop-up message, I am marking this issue as Verified Fixed.
More details about the testing environment can be seen in Comment 20.

Status: RESOLVED → VERIFIED
status-firefox65: fixed → verified
Flags: qe-verify+
Flags: needinfo?(mihai.boldan)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: