Last Comment Bug 574616 - "Unresponsive Script" warning blames/stops the wrong script
: "Unresponsive Script" warning blames/stops the wrong script
Status: NEW
DUPEME
: hang
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
: -- normal with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jason Orendorff [:jorendorff]
Mentors:
https://www.mozdev.org/bugs/show_bug....
: 589116 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-25 03:32 PDT by Wladimir Palant
Modified: 2014-07-24 11:07 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase (Don't open unless you are prepared to kill your browser!) (569 bytes, text/html)
2010-06-25 03:32 PDT, Wladimir Palant
no flags Details

Description Wladimir Palant 2010-06-25 03:32:07 PDT
Created attachment 453997 [details]
Testcase (Don't open unless you are prepared to kill your browser!)

A user filed an Adblock Plus bug under https://www.mozdev.org/bugs/show_bug.cgi?id=22955 claiming that Adblock Plus goes into an infinite loop on a particular website and cannot be stopped. What really happened: the website went into an infinite loop and kept creating new DOM nodes. These triggered content policies, with Adblock Plus taking significantly more time than the tight loop that triggered it. Consequently the script that received the blame was pretty much always Adblock Plus. Stopping it didn't help the user because it only affected the current content policies call, not the actual infinite loop.

The issue described by RSnake under http://ha.ckers.org/blog/20100621/firefox-dos/ is similar, there the warning assigns the blame to NoScript rather than the loop that caused the problem.

It is possible to reproduce this issue without any extensions, see testcase. There the endless loop only changes an attribute on the body tag, the script in the DOMAttrModified event handler does much work however. The warning will always blame the DOMAttrModified event handler and suggest stopping it. This doesn't do anything to stop the endless loop however.

It seems that the handling needs to be different if the stack has native frames between JavaScript frames. I guess that the warning should identify all the frames that are followed by a native frame in addition to identifying the last JavaScript frame on stack. What's more important, it should also be able to stop these frames somehow.

Not marking as security sensitive, this kind of attacks has been widely publicized already.
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2010-06-25 09:03:39 PDT
Pretty sure there's an existing bug about the origin tracking on slow script being broken (e.g. through event handlers, etc).
Comment 2 Wladimir Palant 2010-06-25 09:19:00 PDT
I searched - maybe it has some non-obvious title.
Comment 3 Daniel Veditz [:dveditz] 2010-08-20 09:59:36 PDT
For better dupe-matching, the RSnake demo described above is at
http://ha.ckers.org/weird/side-dos.html
Comment 4 Daniel Veditz [:dveditz] 2010-08-20 10:00:00 PDT
*** Bug 589116 has been marked as a duplicate of this bug. ***
Comment 5 Wayne Mery (:wsmwk, NI for questions) 2010-12-10 12:39:49 PST
bz, regarding comment 1 (dupe) are you thinking of 
 bug 78089 "A script on this page is causing mozilla to run slowly" message is too vague and badly worded
or
 Bug 397394 - unresponsive script should identify culpable tab

and bug 573310 states the script itself isn't running long, but the firefox stuff it calls is running too long?

I didn't find anything else. although bug 470765 about improving diag, but is is mostly WFM

Note You need to log in before you can comment on or make changes to this bug.