Re-sent from the proper email address. On Mon, Jul 6, 2009 at 5:37 PM, Eric Seidel <macd...@gmail.com> wrote:
> Adam and I talked about this feature more in person last night. > I agree with Oliver. Like any feature added to WebCore, it should work > with the default compiled JS engine JavaScriptCore. > > > From taking to Adam, it seems this could be useful for WebKit embedders > like Safari (any context in which you want to make a "pristine view" of the > DOM where nothing could have overridden properties or getters/setters > unexpectedly). > > Currently WebKit avoids this need for Safari directly, by having separate > Obj-C and JS bindings around DOM objects. Properties/getters/setters added > through JS do not affect the Obj-C bindings. Other embedders which call > directly through the JS bindings could currently have implementation > problems w/o Isolated World functionality. > > -eric > > On Wed, Jul 1, 2009 at 11:07 PM, Oliver Hunt <oli...@apple.com> wrote: > >> >> On Jul 1, 2009, at 10:59 PM, Adam Barth wrote: >> >> On Wed, Jul 1, 2009 at 7:50 PM, Maciej Stachowiak<m...@apple.com> wrote: >>> >>>> We generally wouldn't accept WebKit features that only work with V8, >>>> even if >>>> other ports may not immediately plan to use them. >>>> >>> >>> I support this principle. >>> >>> I haven't thought through whether this particular feature >>>> should be an exception. >>>> >>> >>> The main arguments are as follows: >>> >>> 1) Isolated worlds is not a web platform feature. Adding the feature >>> to V8 and not to JSC does not create an incompatibility between the >>> two engines. The observable behavior from web content is the same. >>> >> >> WebKit is not just a web platform API -- it is used in a wide variety >> different applications -- that said, if this feature wasn't relevant to >> WebKit it wouldn't need to be in WebKit >> >> >>> 2) The purpose of implementing isolated worlds is so the app can >>> implement an app-specific feature (extensions). Implementing >>> extensions in another app requires a lot more than just isolated >>> worlds. >>> >> >> However if isolated worlds is necessary to provide effective security >> controls in any application that wished to be extensible in the face of >> arbitrary untrusted content, and it needs to be in webcore (if it doesn't my >> prior comment applies, this doesn't need to be in the webkit tree) then any >> application that wishes to use webkit will need webkit to provide this >> unless every application shipped its own copy of webkit with its own >> implementation of isolated worlds. >> >> >>> 3) I don't foresee the implementation touching any source files >>> outside of WebCore/bindings/v8. Other ports do not need to bear any >>> costs because of isolated worlds. >>> >> >> As i've said if isolated worlds has a real usecase then there is no reason >> to not actually provide it >> >> >>> In general, I think using regression tests for features that are not >>>> directly exposed to Web content, but implemented in WebCore/WebKit, is >>>> reasonable. For example we have tests that check that WebKit's delegate >>>> methods relating to load progress are dispatched in the correct order. >>>> >>> >>> Perhaps I've been indoctrinated into the cult, but I wouldn't want to >>> work on something without writing tests. >>> >> >> Agreed, and what JS engine is being used should not effect the results of >> those tests. >> >> >> _______________________________________________ >> 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