On Jul 6, 2009, at 6:58 PM, Maciej Stachowiak wrote:
On Jul 6, 2009, at 6:44 PM, Oliver Hunt wrote:
On Jul 6, 2009, at 5:37 PM, Eric Seidel wrote:
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.
I'm unsure what you mean by this? V8 could just as easily have COM
or C bindings. The specific issue that "Isolated Worlds" is a
feature designed specifically to deal with potential
vulnerabilities in JavaScript so bindings for other languages
aren't really relevant.
My understanding of "Isolated Worlds" is that it's meant to let
privileged JavaScript code access the DOM of a Web page without the
risk of undesired side effects from pages that are deliberately
trying to hack the privileged JavaScript code. This is to some
extent the same position the Web Inspector finds itself in, for
example. Even with the new proxying code to enable out-of-process
Web Inspector, the Web Inspector may want any code it runs in the
context of the Web page to use Isolated World style bindings. On the
other hand, it needs to be able to break through to the underlying
DOM object as well.
I was meaning JavaScript in the context of the DOM (my bad) -- native
code is implicitly trusted so we don't have the same xss, etc concerns.
--Oliver
- Maciej
--Oliver
-eric
On Wed, Jul 1, 2009 at 11:07 PM, Oliver Hunt <[email protected]>
wrote:
On Jul 1, 2009, at 10:59 PM, Adam Barth wrote:
On Wed, Jul 1, 2009 at 7:50 PM, Maciej Stachowiak<[email protected]>
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
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
