[Webkit-unassigned] [Bug 38152] sandbox iframes have access to top.history methods

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu May 13 15:03:03 PDT 2010


https://bugs.webkit.org/show_bug.cgi?id=38152





--- Comment #9 from Adam Barth <abarth at webkit.org>  2010-05-13 15:03:01 PST ---
> Another option is to overload these functions and have a version without a Frame* argument. This would allow us to distinguish "no concept of frame in this binding" from the other cases where Frame* could be zero.

That seems better than 0 being a magic value.

> Why doesn't this break the Objective-C binding?

I don't know.  Maybe the history object isn't exposed via these mechanisms?  I assumed they would fail to compile if they were unhappy.

> I think we should move in the direction of the term "active frame" to sync up with HTML5 terminology, if we can do so without sacrificing clarity. Or we could sync up the V8 and JSC terminology for the frames.

I'll post a global rename patch separately.  In HTML5 there is an "active script" and a "first script".  The first script is what we call the dynamic global object.

> > +    if (activeFrame && !activeFrame->loader()->shouldAllowNavigation(m_frame))
> > +        return;
> >      m_frame->redirectScheduler()->scheduleHistoryNavigation(-1);
> 
> Is there any problem with the distance in time between this check and the actual navigation? Perhaps the document in the active frame at the time the navigation was scheduled should be recorded by the redirect scheduler so the test can be done at the correct time?

I thought about that situation, but I think it's ok.  There are two cases:

1) The target frame gets navigated while the history navigation is queued up.  In this case, all the scheduled redirects (including the history navigation) are cancelled.

2) The active frame gets navigated while the history navigation is queued up.  In this case, don't want to use the new document for the security check anyway.

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



More information about the webkit-unassigned mailing list