[Webkit-unassigned] [Bug 21288] Implement HTML5's sandbox attribute for iframes

[bugzilla-daemon at webkit.org]

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





--- Comment #33 from Patrik Persson <patrik.j.persson at ericsson.com>  2009-11-16 11:16:06 PST ---
(In reply to comment #31)
> (From update of attachment 43307 [details])

Before we revise the patch, I'd just like to make sure I understand you right.

> > +bool HTMLAppletElement::isJavaEnabled() const
> > +{
> > +    if (!inDocument())
> > +        return false;
> 
> This is a policy change. Before there was no check of inDocument. I presume
> this change is done because it fixes a bug. Is there a test that shows why this
> improves things? Can this bug fix be done in a separate patch?

My mistake. I really intended to do "if (document())", since document() is
dereferenced further down in the code.

> > +void HTMLFrameOwnerElement::updateSandboxFlags()
> > +{
> > +    ...
> > +}
> 
> The logic here should be moved to FrameLoader.

I see. I'll prepare a patch with the logic currently in Frame, and as much as
possible of the logic in the HTMLFrameOwnerElement, moved to the FrameLoader.

> I think it is strange that isSameSchemeHostPort is checking the sandboxing
> flags. That function now doesn't make as much sense as before, because it can
> return false even if you ask if a security origin is the same as itself. Are
> you sure that's the bst design for this? Can we look at call sites and consider
> a different approach?

I did this in response to comment #22. It should probably return true when
other==this, though. It does so without the patch, so such a check shouldn't
break anything.

> Where is the code where a new document gets its security origin flags set based
> on the frame it is created in?

Currently in Frame::inheritSandboxFlags() and Document::initSecurityContext().

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