Shipping Blink-in-JS

[Kentaro Hara]

Hi

Since the infrastructure of Blink-in-JS is now ready, I'm planning to start shipping DOM features with Blink-in-JS.

The biggest concern of Blink-in-JS was security. As explained in this slide, Blink-in-JS uses the same security model as content scripts of Chrome extensions. Specifically, Blink-in-JS uses a dedicated isolated world to guarantee that no JavaScript objects are shared between user's script and Blink-in-JS. However, the problem was that the existing isolation among the isolated worlds was broken, and thus there had been multiple ways to leak JavaScript objects between user's script and Blink-in-JS (this means that the security isolation of Chrome extensions had been broken as well). I've fixed those cross-world leakages and inserted a couple of RELEASE_ASSERTs to catch the cross-world leakages two months ago. As of now, I've received no suspicious crash reports caused by the RELEASE_ASSSERTs, so I think it's now OK to say that the cross-world leakages were fixed.

abarth@ and I implemented a <marquee> element in Blink-in-JS and confirmed that Blink-in-JS is powerful enough to implement a built-in HTML element. tasak@ started implementing XSLT in Blink-in-JS. We also have a plan to move editing/ and SMIL animations to Blink-in-JS. We're planning to address specific concerns in each code review, but if you have any general concern about shipping Blink-in-JS, feel free to ping me.

I explained how to use Blink-in-JS in this Chromium page.

Thanks!

====================

Note: Unfortunately I cannot ship the <marquee> element in Blink-in-JS at the moment because it uses Web Animation APIs behind a runtime flag.

Note: Blink-in-JS improves user experience of the <marquee> element :) Since the <marquee> element in Blink-in-JS uses Web Animations, the element is animated more smoothly than the current C++ implementation where Blink timers are used. I created a video to show you how the user experience of the <marquee> element is improved.

Note: I also implemented a <blink> tag in Blink-in-JS. If you want it, I'm happy to write an intent-to-ship :D (This is just a joke, but it's worth emphasizing that I was able to implement the <blink> tag in 30 mins. Blink-in-JS is really easy to implement.)

--
Kentaro Hara, Tokyo, Japan

[Adam Barth]

On Sun Jul 27 2014 at 5:45:16 PM Kentaro Hara <har...@chromium.org> wrote:

Hi

Since the infrastructure of Blink-in-JS is now ready, I'm planning to start shipping DOM features with Blink-in-JS.

The biggest concern of Blink-in-JS was security. As explained in this slide, Blink-in-JS uses the same security model as content scripts of Chrome extensions. Specifically, Blink-in-JS uses a dedicated isolated world to guarantee that no JavaScript objects are shared between user's script and Blink-in-JS. However, the problem was that the existing isolation among the isolated worlds was broken, and thus there had been multiple ways to leak JavaScript objects between user's script and Blink-in-JS (this means that the security isolation of Chrome extensions had been broken as well). I've fixed those cross-world leakages and inserted a couple of RELEASE_ASSERTs to catch the cross-world leakages two months ago. As of now, I've received no suspicious crash reports caused by the RELEASE_ASSSERTs, so I think it's now OK to say that the cross-world leakages were fixed.

abarth@ and I implemented a <marquee> element in Blink-in-JS and confirmed that Blink-in-JS is powerful enough to implement a built-in HTML element. tasak@ started implementing XSLT in Blink-in-JS. We also have a plan to move editing/ and SMIL animations to Blink-in-JS. We're planning to address specific concerns in each code review, but if you have any general concern about shipping Blink-in-JS, feel free to ping me.

I explained how to use Blink-in-JS in this Chromium page.

Thanks!

====================

Note: Unfortunately I cannot ship the <marquee> element in Blink-in-JS at the moment because it uses Web Animation APIs behind a runtime flag.

It shouldn't need anything from Web Animations that's not enabled by default...  Is there something specific that doesn't work?

Adam

[Douglas Stockwell]

On Mon, Jul 28, 2014 at 1:57 PM, Adam Barth <aba...@chromium.org> wrote:

On Sun Jul 27 2014 at 5:45:16 PM Kentaro Hara <har...@chromium.org> wrote:

Hi

Since the infrastructure of Blink-in-JS is now ready, I'm planning to start shipping DOM features with Blink-in-JS.

The biggest concern of Blink-in-JS was security. As explained in this slide, Blink-in-JS uses the same security model as content scripts of Chrome extensions. Specifically, Blink-in-JS uses a dedicated isolated world to guarantee that no JavaScript objects are shared between user's script and Blink-in-JS. However, the problem was that the existing isolation among the isolated worlds was broken, and thus there had been multiple ways to leak JavaScript objects between user's script and Blink-in-JS (this means that the security isolation of Chrome extensions had been broken as well). I've fixed those cross-world leakages and inserted a couple of RELEASE_ASSERTs to catch the cross-world leakages two months ago. As of now, I've received no suspicious crash reports caused by the RELEASE_ASSSERTs, so I think it's now OK to say that the cross-world leakages were fixed.

abarth@ and I implemented a <marquee> element in Blink-in-JS and confirmed that Blink-in-JS is powerful enough to implement a built-in HTML element. tasak@ started implementing XSLT in Blink-in-JS. We also have a plan to move editing/ and SMIL animations to Blink-in-JS. We're planning to address specific concerns in each code review, but if you have any general concern about shipping Blink-in-JS, feel free to ping me.

I explained how to use Blink-in-JS in this Chromium page.

Thanks!

====================

Note: Unfortunately I cannot ship the <marquee> element in Blink-in-JS at the moment because it uses Web Animation APIs behind a runtime flag.

It shouldn't need anything from Web Animations that's not enabled by default...  Is there something specific that doesn't work?

Looks like it uses AnimationPlayer.pause() which we haven't shipped yet.

[Kentaro Hara]

>> Note: Unfortunately I cannot ship the <marquee> element in Blink-in-JS at the moment because it uses Web Animation APIs behind a runtime flag.
>
> It shouldn't need anything from Web Animations that's not enabled by default...  Is there something specific that doesn't work? 

 

Looks like it uses AnimationPlayer.pause() which we haven't shipped yet.

Yes, it needs AnimationPlayer.pause(), AnimationPlayer.play() and AnimationPlayer.ispaused.

[Peter Kasting]

On Sun, Jul 27, 2014 at 5:44 PM, Kentaro Hara <har...@chromium.org> wrote:

Since the infrastructure of Blink-in-JS is now ready, I'm planning to start shipping DOM features with Blink-in-JS.

...

I explained how to use Blink-in-JS in this Chromium page.

I hadn't actually heard of this project before this email.

The links above make some pretty bald statements about maintainability being improved in a JS-based world.  Perhaps this is blindingly obvious, but that's only true when your engineers are comfortable with JS -- for example, I personally am utterly incapable of writing JS in any form.  So anything done via Blink-in-JS is entirely unhackable for me.

Is the assumption that most engineers working on Blink are adept with JS?  That wasn't necessarily true in the very early days of Chrome, but perhaps it's a more reasonable assumption now, and people like me are strange outliers.  If that's true, maybe it's not a big deal if more and more of Blink becomes opaque to a small group.

PK

[Alex Russell]

On Mon, Jul 28, 2014 at 5:14 AM, 'Peter Kasting' via blink-dev <blin...@chromium.org> wrote:

On Sun, Jul 27, 2014 at 5:44 PM, Kentaro Hara <har...@chromium.org> wrote:

Since the infrastructure of Blink-in-JS is now ready, I'm planning to start shipping DOM features with Blink-in-JS.

...

I explained how to use Blink-in-JS in this Chromium page.

I hadn't actually heard of this project before this email.

The links above make some pretty bald statements about maintainability being improved in a JS-based world.  Perhaps this is blindingly obvious, but that's only true when your engineers are comfortable with JS -- for example, I personally am utterly incapable of writing JS in any form.  So anything done via Blink-in-JS is entirely unhackable for me.

Is the assumption that most engineers working on Blink are adept with JS?

I don't think so. But I'd advocate that all engineers working to improve the web platform should be able to recreationally use and build apps with it. If we don't use our own platform we'll never understand the needs of our users.

[Jochen Eisinger]

On Mon, Jul 28, 2014 at 2:14 PM, 'Peter Kasting' via blink-dev <blin...@chromium.org> wrote:

On Sun, Jul 27, 2014 at 5:44 PM, Kentaro Hara <har...@chromium.org> wrote:

Since the infrastructure of Blink-in-JS is now ready, I'm planning to start shipping DOM features with Blink-in-JS.

...

I explained how to use Blink-in-JS in this Chromium page.

I hadn't actually heard of this project before this email.

The links above make some pretty bald statements about maintainability being improved in a JS-based world.  Perhaps this is blindingly obvious, but that's only true when your engineers are comfortable with JS -- for example, I personally am utterly incapable of writing JS in any form.  So anything done via Blink-in-JS is entirely unhackable for me.

I'd expect that the improved hackability comes from removing C++ code. E.g. we could move XSLT and then engineers working on blink wouldn't have to refactor it constantly.

XSLT wouldn't become any more hackability. Probably quite the contrary...

-jochen

[Greg Simon]

Haraken introduced this effort with this January 16 blink-dev posting.

[Adam Barth]

On Sun Jul 27 2014 at 9:51:39 PM Kentaro Hara <har...@chromium.org> wrote:

>> Note: Unfortunately I cannot ship the <marquee> element in Blink-in-JS at the moment because it uses Web Animation APIs behind a runtime flag.
>
> It shouldn't need anything from Web Animations that's not enabled by default...  Is there something specific that doesn't work? 

 

Looks like it uses AnimationPlayer.pause() which we haven't shipped yet.

Yes, it needs AnimationPlayer.pause(), AnimationPlayer.play() and AnimationPlayer.ispaused.

We can probably work around the lack of those APIs by doing some more math when programming animations.  I'll take a look.

@dstockwell: Would you recommend we hack around the lack of those APIs or should we just wait for them to ship?

Adam

[Adam Barth]

On Mon Jul 28 2014 at 5:39:41 AM Jochen Eisinger <joc...@chromium.org> wrote:

On Mon, Jul 28, 2014 at 2:14 PM, 'Peter Kasting' via blink-dev <blin...@chromium.org> wrote:

On Sun, Jul 27, 2014 at 5:44 PM, Kentaro Hara <har...@chromium.org> wrote:

Since the infrastructure of Blink-in-JS is now ready, I'm planning to start shipping DOM features with Blink-in-JS.

...

I explained how to use Blink-in-JS in this Chromium page.

I hadn't actually heard of this project before this email.

The links above make some pretty bald statements about maintainability being improved in a JS-based world.  Perhaps this is blindingly obvious, but that's only true when your engineers are comfortable with JS -- for example, I personally am utterly incapable of writing JS in any form.  So anything done via Blink-in-JS is entirely unhackable for me.

I'd expect that the improved hackability comes from removing C++ code. E.g. we could move XSLT and then engineers working on blink wouldn't have to refactor it constantly.

Exactly.  As another example, our current <marquee> implementation internally uses scrolling to drive its visual effect, but it uses a hacked up version of scrolling that doesn't play by the same rules as normal scrolling on the web.  That means the scrolling code is littered with special cases for <marquee>

One of the benefits of lifting these features in JavaScript is that they're forced to play by the same rules that authors are forced to play by.  That makes the rest of the codebase more hackable because they don't impose any more constraints on the system than we already have for supporting the web.

With <marquee> in particular, I'm not sure we achieved that goal perfectly.  We found a number of places where custom elements and shadow DOM not quite work perfectly for our use case.  I'd like to feed that information back into the custom elements and shadow DOM standards process so that future versions of those standards will be powerful enough to implement <marquee>.

XSLT wouldn't become any more hackability. Probably quite the contrary...

Yes, but no one hacks on XSLT.  In fact, we've actively resisted improving our XSLT implementation.

For XSLT, I'd ideally like to make it possible for authors to take the JavaScript version we use in the engine and customize it for use on their own site.  That way people who care about XSLT can form a community and improve XSLT themselves without needing to lobby browser developers to spend our engineering resources on XSLT.

In that sense, lifting XSLT into JavaScript makes the system more hackable because a much wider group of people (web developer rather than browser developers) can hack on XSLT.

Adam

[Peter Kasting]

On Mon, Jul 28, 2014 at 8:25 AM, Adam Barth <aba...@chromium.org> wrote:

Exactly.  As another example, our current <marquee> implementation internally uses scrolling to drive its visual effect, but it uses a hacked up version of scrolling that doesn't play by the same rules as normal scrolling on the web.  That means the scrolling code is littered with special cases for <marquee>

One of the benefits of lifting these features in JavaScript is that they're forced to play by the same rules that authors are forced to play by.  That makes the rest of the codebase more hackable because they don't impose any more constraints on the system than we already have for supporting the web.

With <marquee> in particular, I'm not sure we achieved that goal perfectly.  We found a number of places where custom elements and shadow DOM not quite work perfectly for our use case.  I'd like to feed that information back into the custom elements and shadow DOM standards process so that future versions of those standards will be powerful enough to implement <marquee>.

Thanks for that example.  I think it's illustrative and reasonable in terms of motivating this sort of thing.

PK 

[Douglas Stockwell]

On Tue Jul 29 2014 at 1:15:03 AM Adam Barth <aba...@chromium.org> wrote:

On Sun Jul 27 2014 at 9:51:39 PM Kentaro Hara <har...@chromium.org> wrote:

>> Note: Unfortunately I cannot ship the <marquee> element in Blink-in-JS at the moment because it uses Web Animation APIs behind a runtime flag.
>
> It shouldn't need anything from Web Animations that's not enabled by default...  Is there something specific that doesn't work? 

 

Looks like it uses AnimationPlayer.pause() which we haven't shipped yet.

Yes, it needs AnimationPlayer.pause(), AnimationPlayer.play() and AnimationPlayer.ispaused.

We can probably work around the lack of those APIs by doing some more math when programming animations.  I'll take a look.

@dstockwell: Would you recommend we hack around the lack of those APIs or should we just wait for them to ship?

I think it will be difficult to hack around this accurately. Best to wait -- I hope to ship playback control (play/pause, etc) in the near future (weeks).