[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