[webkit-dev] Feature Announcement: Adding <iframe seamless>
jarred at webkit.org
Wed May 2 06:14:52 PDT 2012
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
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev