[Webkit-unassigned] [Bug 17133] Should support pausing JavaScript execution without hanging the process

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Mar 13 21:07:31 PDT 2008


http://bugs.webkit.org/show_bug.cgi?id=17133





------- Comment #28 from aroben at apple.com  2008-03-13 21:07 PDT -------
(In reply to comment #26)
> (In reply to comment #25)
> > Here are the ways I currently know that JavaScript execution can be initiated:
> > 7. Loading of javascript: URIs
> 
> I don't yet have a solution for this.

I think I now understand how to deal with this.

Here are the ways a javascript: URI may be evaluated:

A. Parsing of a <frame>/<iframe> tag that has a javascript: URI as the value of
its src attribute

   This can be prevented by Page::setDefersLoading(true), just as with parsing
of <script> elements.

B. Programmatically changing window.location or the src attribute of a
<frame>/<iframe> to a javascript: URI

   This will be prevented simply because we're going to be pausing JavaScript.

C. User activating an <a> that has a javascript: URI as the value of its href
attribute
D. User submitting a form that has a javascript: URI as the value of its action
attribute

   These we will need to block. Programmatic activation/submission (e.g.,
anchor.click()/form.submit()) should be allowed.

E. "Navigation" of the main frame to a javascript: URI by the WebKit client

   This falls under the general category of calls from WebKit clients that
execute JavaScript (this is item (8) from comment 25). I'm not concerned with
this right now.

So, all we need to do is make sure that the link's/form's javascript: URI is
not evaluated if the user clicks a link/submits a form.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list