[webkit-dev] Feature Announcement: Adding <iframe seamless>

[Jarred Nicholls]

On Tue, May 1, 2012 at 7:39 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On May 1, 2012, at 4:04 PM, Adam Barth <abarth at webkit.org> wrote:
>
> > On Tue, May 1, 2012 at 3:50 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> >> On May 1, 2012, at 3:31 PM, Eric Seidel <eric at webkit.org> wrote:
> >>> Is your goal to be able to disable the feature to prevent a late-known
> >>> security issue?
> >>>
> >>> Or is your goal to universally disable seamless for a port entirely?
> >>
> >> I'm not sure I understand the difference between these. The capability
> I'm looking for is to disable the entire feature if necessary. However, I
> don't expect that any ports Apple is involved with would leave it off
> indefinitely. I hope that answers your questions.
> >
> > One approach to ENABLE_SEAMLESS is to put the "seamless" property on
> > HTMLIFrameElement behind [Conditional=SEAMLESS] and then to change
> > Document::mayDisplaySeamlessWithParent to always return false.  That
> > should make the feature invisible to the web.  The changes to the
> > layout and navigation algorithms wouldn't be ifdefed, but they'll do
> > the same things they do today because the engine won't ever treat an
> > iframe as seamless.
>
> I'm not too picky about how it's done, but I'd feel more comfortable with
> #ifdef protecting the code changes rather than if(). If the changes are so
> entangled that it's not easy to put only the changes in an ifdef, then I
> would be skeptical that they actually have no possible effect on the
> non-seamless case.


Do we not have sufficient tests to lend us more confidence in this area?


> If they aren't that entangled, then adding the right #ifdef should be
> straightforward.
>
> Regards,
> Maciej
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120502/fca43d0c/attachment.html>