On Tue, May 1, 2012 at 7:39 PM, Maciej Stachowiak <m...@apple.com> wrote:
> > On May 1, 2012, at 4:04 PM, Adam Barth <aba...@webkit.org> wrote: > > > On Tue, May 1, 2012 at 3:50 PM, Maciej Stachowiak <m...@apple.com> wrote: > >> On May 1, 2012, at 3:31 PM, Eric Seidel <e...@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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

