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. 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

