<marquee>, web components, and Blink-in-JS

[Adam Barth]

I've re-implemented the <marquee> element in JavaScript using web components:

https://github.com/abarth/marquee/blob/master/marquee.js

In the interests of streamlining the engine by self-hosting more features, I wonder if we should consider replacing our current implementation of <marquee> with this implementation running in Blink-in-JS.  (Gecko's implementation of <marquee> is similarly self-hosted in XBL.)

Thoughts?

Adam

[Harald Alvestrand]

(tangential)

if there is a way to sensibly do self-hosted JS in blink, I'd very much like to know. There are a number of features in the WebRTC spec, and in the tricks we do for backwards compatibility, that just seem to cry out for a JS implementation.

Last time I asked around, the response was something like "not without side effects we don't like".

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[PhistucK]

Is that totally separate from the JavaScript of the page?

(Say, a page overrides and neutralizes Object.defineProperty, string.prototype.match and so - will it break your code?)

I ask because I know Chrome extension API implementations (browser side) had problems with such implementations.

☆PhistucK

[addyo...@gmail.com]

I'm curious if agreeing to this might set a precedent for future simplistic tags to similarly be implemented using Custom Elements in Blink-in-JS.

It would certainly open the doors up to more patch contributions from the JS community.

[Kentaro Hara]

Adam:

In the interests of streamlining the engine by self-hosting more features, I wonder if we should consider replacing our current implementation of <marquee> with this implementation running in Blink-in-JS.  (Gecko's implementation of <marquee> is similarly self-hosted in XBL.) 

 

Thoughts?

It's a great idea to implement these high-level DOM features in JavaScript. It improves the layering of the Blink architecture and simplifies the code base. Simplifying the code base is important to make more performance improvement and implement more important features more quickly.

Here is an update of Blink-in-JS (For more details, see https://code.google.com/p/chromium/issues/detail?id=341031):

(1) We finished removing all cross-world wrapper leakage we're aware of from the code base.

(2) We inserted RELEASE_ASSERTs to verify that there is no cross-world wrapper leakage two weeks ago. At the moment, we're not hitting the RELEASE_ASSERTs. (When we inserted the RELEASE_ASSERTs one year ago, we hit them a lot of times.) If we don't hit the RELEASE_ASSERTs for a certain period of time, we can conclude that we have no cross-world wrapper leakage.

(3) I started implementing an infrastructure of Blink-in-JS. I think I can land the infrastructure in one or two weeks and you can start experimenting Blink-in-JS locally (for XSLT, editing, marquee element, WebRTC etc).

(4) Once we conclude that we have no cross-world wrapper leakage, we can start landing XSLT, editing etc in Blink-in-JS.

PhistucK:

Is that totally separate from the JavaScript of the page?
(Say, a page overrides and neutralizes Object.defineProperty, string.prototype.match and so - will it break your code?) 

 

I ask because I know Chrome extension API implementations (browser side) had problems with such implementations.

Yes. Blink-in-JS runs in a separate world from user's JavaScript. No JavaScript objects are shared between user's JavaScript and Blink-in-JS. (As explained above, we've fixed a lot of cross-world leakage and inserted RELEASE_ASSERTs to catch the leakage if any.)

--
Kentaro Hara, Tokyo, Japan

[Kentaro Hara]

I'm curious if agreeing to this might set a precedent for future simplistic tags to similarly be implemented using Custom Elements in Blink-in-JS.

I think that's a good way to go. It would be a good idea to implement not-{performance,memory,power}-sensitive tags using custom elements + Blink-in-JS, and thus factor out the complexity from Blink C++.

On Sun, Jun 15, 2014 at 5:24 PM, <addyo...@gmail.com> wrote:

I'm curious if agreeing to this might set a precedent for future simplistic tags to similarly be implemented using Custom Elements in Blink-in-JS.

It would certainly open the doors up to more patch contributions from the JS community.

[Adam Barth]

On Sun Jun 15 2014 at 12:24:45 AM, Harald Alvestrand <h...@google.com> wrote:

(tangential)

if there is a way to sensibly do self-hosted JS in blink, I'd very much like to know. There are a number of features in the WebRTC spec, and in the tricks we do for backwards compatibility, that just seem to cry out for a JS implementation.

Yes, WebRTC is a good candidate for Blink-in-JS.  As haraken wrote, it's not quite working yet, but hopefully we'll have something usable soon.

For WebRTC specifically, we might want to consider an implementation that runs in Blink-in-JS and talks directly to the browser process via Mojo.  For folks who aren't familiar with Mojo, it's a reboot of Chrome's IPC system, and one of the changes is that it's possible for JavaScript to directly send IPC messages to the browser to without needing to write any C++ code in the renderer.  Hopefully the combination of Mojo and Blink-in-JS will let us cut out many redundant layers of abstraction.

Last time I asked around, the response was something like "not without side effects we don't like".

Blink-in-JS aims to solve the security side effects, which was the main blocker before.

Adam

[Dimitri Glazkov]

Huge fan of this! Blink-in-JS is a great first step toward understanding what it means to self-host Web platform.

:DG<

[Adam Barth]

Where's a good place to report missing pieces in web components?  There were a couple things that I couldn't implement correctly because they're magic pieces of the platform we haven't explained yet.  For example, my implementation of <marquee>'s presentational attribute isn't correct because I've translated the presentational attributes into inline CSS declarations, but authors might supply their own inline CSS.  I don't know of any way to implement presentational attributes in a way that cascades correctly.

Adam

[Ojan Vafai]

This certainly seems like a good first place to try out Blink-in-JS. It's very simple, but it would help us remove a surprising amount of complexity in the render tree.

[Dimitri Glazkov]

This is where we've been collecting them so far: https://github.com/dglazkov/html-as-custom-elements/issues?labels=primitive&page=1&state=open

[Adam Barth]

Filed: https://github.com/dglazkov/html-as-custom-elements/issues/27

I'm not sure how to give it the right label...

Adam

[Domenic Denicola]

On Sunday, June 15, 2014 4:33:12 AM UTC-4, Kentaro Hara wrote:

PhistucK:

Is that totally separate from the JavaScript of the page?
(Say, a page overrides and neutralizes Object.defineProperty, string.prototype.match and so - will it break your code?) 

 

I ask because I know Chrome extension API implementations (browser side) had problems with such implementations.

Yes. Blink-in-JS runs in a separate world from user's JavaScript. No JavaScript objects are shared between user's JavaScript and Blink-in-JS. (As explained above, we've fixed a lot of cross-world leakage and inserted RELEASE_ASSERTs to catch the leakage if any.)

Hmm, could you explain how this works, so I could update my mental model? For example, how is the Blink-in-JS code able to use e.g. `someObj.hasOwnProperty` without being susceptible to the page changing `Object.prototype.hasOwnProperty`, and yet it is still producing objects that inherit from the page's `Object.prototype`?

My naive mental model doesn't work very well. For example, when implementing (say) HTMLDivElement.prototype.align's getter, I might do `this.getAttribute("align")`. But what if someone on the page overwrote `Element.prototype.getAttribute`?

The solution I thought we'd have to do was to save a reference to anything potentially under user control, and then ensure the Blink code gets run first. So instead of doing `this.getAttribute("align")`, we would (at the top of the script) say `getAttribute = Element.prototype.getAttribute`, and then later, do `getAttribute.call(this, "align")`. Is that still necessary with Blink-in-JS's protections, or did you find a way around such contortions?

[Adam Barth]

On Sun Jun 15 2014 at 11:54:54 AM, Domenic Denicola <dom...@domenicdenicola.com> wrote:

On Sunday, June 15, 2014 4:33:12 AM UTC-4, Kentaro Hara wrote:

PhistucK:

Is that totally separate from the JavaScript of the page?
(Say, a page overrides and neutralizes Object.defineProperty, string.prototype.match and so - will it break your code?) 

 

I ask because I know Chrome extension API implementations (browser side) had problems with such implementations.

Yes. Blink-in-JS runs in a separate world from user's JavaScript. No JavaScript objects are shared between user's JavaScript and Blink-in-JS. (As explained above, we've fixed a lot of cross-world leakage and inserted RELEASE_ASSERTs to catch the leakage if any.)

Hmm, could you explain how this works, so I could update my mental model? For example, how is the Blink-in-JS code able to use e.g. `someObj.hasOwnProperty` without being susceptible to the page changing `Object.prototype.hasOwnProperty`, and yet it is still producing objects that inherit from the page's `Object.prototype`?

The security model for Blink-in-JS is the same as for content scripts in Chrome's extension system.  Both run in an isolated world, which means they have a completely disjoint JavaScript heap from author scripts.  See figures 7 and 8 in this paper:

http://www.adambarth.com/papers/2010/barth-felt-saxena-boodman.pdf

They're able to produce objects that inherit from the page's Object.prototype in the same way that we can produce C++ objects that inherit from the page's Object.prototype.  Specifically, the author-exposed objects are defined in WebIDL, just like for interfaces that are backed by C++ objects.  In both cases, authors call through a C++ trampoline to reach Blink's implementation.  In the C++ case, the trampoline calls into a C++ symbol in the binary.  In the Blink-in-JS case, the trampoline calls into JavaScript running in another isolated world.  In both cases, the trampoline takes care of marshalling objects between author JavaScript and the Blink implementation (be it in C++ or JavaScript).

My naive mental model doesn't work very well. For example, when implementing (say) HTMLDivElement.prototype.align's getter, I might do `this.getAttribute("align")`. But what if someone on the page overwrote `Element.prototype.getAttribute`?

Blink-in-JS sees clean versions of all these functions because it has separate wrappers for all the DOM objects.  You can try this with content scripts today if you want to see how this works.

The solution I thought we'd have to do was to save a reference to anything potentially under user control, and then ensure the Blink code gets run first. So instead of doing `this.getAttribute("align")`, we would (at the top of the script) say `getAttribute = Element.prototype.getAttribute`, and then later, do `getAttribute.call(this, "align")`.

Yes, but that's extremely difficult to do correctly.  We've tried a few experiments along those lines, but when studying our implementations carefully, we're always able to find subtle vulnerabilities.  For that reason, we've abandoned that approach.

 

Is that still necessary with Blink-in-JS's protections, or did you find a way around such contortions?

That's not necessary with Blink-in-JS.  You can just write normal, idiomatic JavaScript.  The trade-off is that you need to define the interface between your JavaScript and author JavaScript in WebIDL in order to generate the C++ trampolines.  However, for web platform features, that's probably a good idea anyway.  :)

Adam

 

[Adam Barth]

haraken has a design doc for Blink-in-JS that explains the system in more detail:

https://docs.google.com/a/google.com/document/d/13cT9Klgvt_ciAR3ONGvzKvw6fz9-f6E0FrqYFqfoc8Y/edit#

[matt.p...@gmail.com]

I feel a bit silly pointing this out, I find it hard to believe it's not intentional...

A couple of variables have "precentage" rather than "percentage".

Apologies if I've just wasted everyone's time... :)

Matt

[Adam Barth]

Fixed.  Please feel free to report bugs on GitHub rather than on this mailing list:

https://github.com/abarth/marquee/issues/new

Adam

[PhistucK]

Or simply submit pull requests, right? :)

☆PhistucK

[Adam Barth]

Sure!  :)