[webkit-dev] Isolated world tests

Maciej Stachowiak mjs at apple.com
Mon Jul 6 18:02:21 PDT 2009


That sounds like a reasonable direction. I do think future JSC-port- 
based products such as Safari may want Isolated World behavior. I  
could even imagine it being useful for WebKit's own Web Inspector in  
the same-process case. I was going to reply to Adam's last comment,  
and point out that (a) his reasons for implementing for V8 only sound  
reasonable, but (b) I think JSC-based ports may want the functionality  
in the near if not immediate future, and would that change his mind on  
the right way to do the work?

However, doing it for both JS engines removes any doubt about this  
work, in my opinion.

Also, to clarify: I think the tests for this functionality should be  
part of the WebKit regression test suite. I think I was pretty clear  
on this before. I think this would be true even for a V8-only feature  
that was implemented in the engine, and even if that feature was not  
part of the Web platform. The WebKit API on Mac has many capabilities  
that are only relevant to an embedder, not to Web content as such, but  
nontheless we consider it important to keep them under test as much as  
we can.

REgards,
Maciej

On Jul 6, 2009, at 5:39 PM, Eric Seidel wrote:

> Re-sent from the proper email address.
>
> On Mon, Jul 6, 2009 at 5:37 PM, Eric Seidel <macdome at 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 <oliver at 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<mjs at 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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
> _______________________________________________
> 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/20090706/0a4a3c53/attachment-0001.html>


More information about the webkit-dev mailing list