Alerts are supposed to be modal (and I think they are), so it's not possible to have more than one at a time from the same window. Window.open is another story. Any web site can open as many new windows as it wants. This is true for 4x, IE, and probably Opera as well. Maybe we want to do something about this, maybe not. Moving to DOM component to decide.
Assignee: jband → jst
QA Contact: rginda → desale
There are lots of ways to make Mozilla unresponsive, and we really can't stop them all. Sorry, but this just isn't something we can prevent right now. THe best defense aginst denial of service is not to visit the offending site again.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED
If I remember correctly, the console is supposed to have a relatively small circular buffer, which makes me wonder if there's some sort of leakage that's happening. It could also be that XUL is taking care of the content model for stuff that's long since offscreen, and that outliner-ifying things would help.
Severity: critical → normal
Status: VERIFIED → REOPENED
Component: DOM Level 0 → XP Apps
Resolution: WONTFIX → ---
Summary: Remote Sites possibly able to Freeze/Hang or DoS Mozilla → JS console sucks down memory and CPU
Reassigning to jag, as I think it's more in his area.
Assignee: jst → jaggernaut
Status: REOPENED → NEW
Still seeing this....it will fill up and continually loop forever. There is no way to stop it in addition to stop it sucking up memory as it grows larger and larger. Build: 2001080904
Keywords: mlk, perf
Erh, no thanks.
Assignee: jaggernaut → pchen
QA Contact: desale → sairuh
nav triage team: We probably want to figure out what's going wrong here but won't happen right away. Marking p2, nsbeta1+, helpwanted, and mozilla1.0.1
Keywords: helpwanted, nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla1.0.1
I think I've noticed this especially when I leave strict JS warninges enabled and Chatzilla is running. With the strict JS warnings CZ generates, it adds up. I've got a testcase from something bzbarsky put together; basically a strict JS warning generator. It's supposed to generate 100 warnings; with strict JS warning tracking enabled on my 56MB system, swapfile usage goes through the roof and it can take over a minute to finish the test. Personal experience shows the performance hit lingers on after the test is complete. Anyone interested in the testcase?
Sure, attach that testcase. Although this is pretty much a duplicate of bug 78179. I tried just having the JS Console refuse to append any rows to its widget, but the JS Engine is still bogged down in handling the endless script warnings generated on e.g., http://www.wocs.dk, from bug 78179. In other words, the defence for this has to come from where the messages are being generated; this isn't really a case where building content in the UI is cause of the lockup.
Created attachment 59021 [details] Testcase involving strict JS Warnings The effect of this testcase is negligible unless you have strict JS warnings enabled. With them enabled... :-/
Rob: I know how you love strict-mode warnings... ;-)
http://lxr.mozilla.org/mozilla/source/xpcom/base/nsConsoleService.cpp#63 Looks to me like we're supposed to wrap after 250 messages. If someone else is holding a reference to the messages (JS Console UI perhaps), the memory won't be reclaimed. Someone could try changing |mBufferSize = 250;| to |mBufferSize = 2;|, and disconnect the JS Console UI listener. Memory should not grow substantially, and performance should not be affected too much. If it is, then someone is leaking.
Just out of curiousity, the three lines preceding line 63 in the above link seem to indicate this should be a preference. Is there one, and if so, what is it?
Incidentally, this bug and bug 104549 combine to generate a sizable performance hit. The sooner we get either one of these two bugs fixed, the better.
Assignee: pchen → hewitt
I got clobbered this week by this bug. Even after optimizing my script, memory was continuously allocated and my routine never returned. Running without the console open fixed the problem. To reproduce w/o strict mode, do a simple table sort with about 500 elements. I cribbed my code from http://webfx.eae.net/dhtml/tablesort/tablesort.js and cleaned it up so as to fetch the inner text only once before the sort, and not during the sort in the compare (same with the cast). The warning about el.innerText not existing throws Mozilla off in to the weeds.
Status: NEW → RESOLVED
Last Resolved: 17 years ago → 11 years ago
Resolution: --- → WORKSFORME
Component: Error Console → Error Console
Product: SeaMonkey → Core Graveyard
You need to log in before you can comment on or make changes to this bug.