Similar to bug 370860 but still happening even after that one has been fixed in 188.8.131.52 bug 370860 dealt with a lot of slashes ('////////....') and the URL in question here is a lot of text ('aaaaaa....'). Reported as a crash on Full-Disclosure, but I and several F-D readers only see a CPU spike. http://archives.neohapsis.com/archives/fulldisclosure/2007-05/0005.html Turning off the phishing protection option in prefs makes the problem go away.
Testcase originally from http://www.critical.lt/research/opera_die_happy.html Had to zip the testcase for size, access it using Mozilla browsers as jar:https://bugzilla.mozilla.org/attachment.cgi?id=263384!/opera_die_happy.html
If there's an easy fix and we need a re-spin for some reason it would be worth getting this one into 184.108.40.206. But since there's an easy workaround (turn off phishing protection) and it's just a resource hog and the similar bug 370860 required re-writing JS bits as C++ I don't think this is a true blocker.
I'm indeed seeing a crash, when I'm closing the tab with the long url, I was using a Bon Echo build of 2007-04-27. I'm getting useless talkback ID's, though: Talkback ID: TB31715490M msvcrt.dll + 0x378c0 (0x77c178c0)
I did manage to crash once (TB31715128), which looks like bug 282660.
It's likely that the patch on bug 368998 fixes this performance issue.
On my trunk build, the above jar URL takes about ~5-6 seconds. But you can always make a longer URL and the time is still going to be linear w.r.t. URL length.
From TB31715128: Stack Signature jsds_NotifyPendingDeadScripts 6d364232 Product ID Firefox2 Build ID 2007043003 Trigger Time 2007-05-01 13:33:29.0 Platform Win32 Operating System Windows NT 5.1 build 2600 Module jsd3250.dll + (00004caf) URL visited User Comments Since Last Crash 104638 sec Total Uptime 104638 sec Trigger Reason Access violation Source File, Line No. c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/jsd/jsd_xpc.cpp, line 501 Stack Trace jsds_NotifyPendingDeadScripts [mozilla/js/jsd/jsd_xpc.cpp, line 501] jsds_GCCallbackProc [mozilla/js/jsd/jsd_xpc.cpp, line 519] js_NewGCThing [mozilla/js/src/jsgc.c, line 1420] js_NewString [mozilla/js/src/jsstr.c, line 2442] js_NewStringCopyZ [mozilla/js/src/jsstr.c, line 2576] JS_NewUCStringCopyZ [mozilla/js/src/jsapi.c, line 4497] nsXPCWrappedJSClass::CallMethod [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1300] nsXPCWrappedJS::CallMethod [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468] SharedStub [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147] nsContentTreeOwner::SetStatus [mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp, line 431] nsWebShell::OnOverLink [mozilla/docshell/base/nsWebShell.cpp, line 587] nsGenericElement::TriggerLink [mozilla/content/base/src/nsGenericElement.cpp, line 3754] nsGenericHTMLElement::HandleDOMEventForAnchors [mozilla/content/html/content/src/nsGenericHTMLElement.cpp, line 1737] nsHTMLAnchorElement::HandleDOMEvent [mozilla/content/html/content/src/nsHTMLAnchorElement.cpp, line 295] nsEventStateManager::SendFocusBlur [mozilla/content/events/src/nsEventStateManager.cpp, line 4452] nsEventStateManager::SetContentState [mozilla/content/events/src/nsEventStateManager.cpp, line 4089] nsGlobalWindow::RestoreWindowState [mozilla/dom/src/base/nsGlobalWindow.cpp, line 7454] nsDocShell::RestoreFromHistory [mozilla/docshell/base/nsDocShell.cpp, line 5536] HandleRestorePresentationEvent [mozilla/docshell/base/nsDocShell.cpp, line 5115] shdocvw.dll + 0x150c24 (0x778b0c24) nsSimplePageSequenceFrame::Reflow [mozilla/layout/generic/nsSimplePageSequence.cpp, line 240] 0x83575653
that stack would be bug 282660. If it's reproducable, it'd be greatly appreciated if you added some logging and figured out what it means for the script to be null.
bug is fixed in firefox 220.127.116.11 ?
not fixed. Changelog++
Is this really still unfixed?
The latest Linux nightly doesn't crash, but it does take a long time and chew up CPU.
Not blocking on this bug for final ship. Would take a safe enough patch if one comes through.
The original test case now returns a 403. When trying to open the jar URL from comment 2, I get: "Unsafe File Type The page you are trying to view cannot be shown because it is contained in a file type that may not be safe to open. Please contact the website owners to inform them of this problem. Please contact the website owners to inform them of this problem." Since it cannot be reproduced anymore, I'll close this bug.