Binding team snippet

[Kentaro Hara]

(haraken, all) Discussed Q3 goals of the binding team. In short, we'll focus on the following items in Q3:

- Make Window attributes conformant with the spec

- Make cross-origin security checks more correct

- Understand all places where Blink keeps strong Persistent handles to V8 objects and make sure that they don’t leak

- Support V8 contexts (and Blink objects that are likely to leak V8 contexts) in the leak detector and fix the leaks

- IDL union type that mixes core/ types and modules/ types should work

- Web API changes in IDL files should be visualized in the Chrome dashboard page (Intern project)

(yukishiino) Implemented a per-attribute/method [Exposed] IDL attribute in the IDL compiler. It is needed for EventHandlers in ServicePortCollection.

(jochen) Implementing PromiseRejectionEvent in a way in which (1) ScriptValues held by the event don't cause memory leak and (2) ScriptValues held by the event don't cause cross-world wrapper leaks. Once the implementation is done, we plan to use the same mechanism in other Events (CustomEvent.detail, PopStateEvent.state etc) and fix their leaks.

(tdresser, yukishiino, haraken) Discussing a way to implement a binding layer for scroll customization in a safe fashion.

(tasak) Trying to reland the core-module componentization. (We landed the change a couple of times but it was reverted due to clang issues.)

--

Kentaro Hara, Tokyo, Japan

[Kentaro Hara]

(yukishiino) Fixed a long-standing bug that one DOM object can end up with having two different wrappers (in a very weird scenario). Fixed a performance issue related to the fix.

(haraken, jochen) Improved ScriptState APIs and replaced toV8Context()s in the code base with the new ScriptState APIs (which are safer and easier to use).

(haraken, jochen) Investigating a design of managing wrapper reachability (i.e., [SetWrapperRerefenceTo] and [SetWrapperReferenceFrom]).

[Philip Jägenstedt]

On Mon, Jul 6, 2015 at 2:13 AM, Kentaro Hara <har...@chromium.org> wrote:
> (haraken, jochen) Investigating a design of managing wrapper reachability (i.e., [SetWrapperRerefenceTo] and [SetWrapperReferenceFrom]).

This sounds interesting, can you share any details about this?

[Kentaro Hara]

That's a very involved issue about the semantics of [SetWrapperReferenceFrom] and [SetWrapperReferenceTo]. I explained the problem here (https://codereview.chromium.org/1200613002/#msg14) in details.

In short, the wrapper lifetime management is super complicated, but Oilpan will fix it in the near future :)

[Kentaro Hara]

Hi

(yukishiino) Exposing JS getters/setters on almost all remaining DOM attributes (except for Window's attributes and constructors; CL: https://codereview.chromium.org/1193793003/). There were a lot of complexity to expose JS getters/setters on [Unforgeable] attributes because of the unfortunate design of V8 APIs and the IDL compiler.

(haraken) Stopped creating a new wrapper in visitDOMWrapper generated by [SetWrapperReferenceTo] and fixed a long-standing crash in a V8 GC prologue (https://code.google.com/p/chromium/issues/detail?id=467211). Now the semantics of [SetWrapperReferenceTo/From] are clearer: [SetWrapperReferenceTo=Y] on X creates a hidden reference from X's wrapper to the object group which Y belongs to (Nothing happens if the object group doesn't contain any wrapper). [SetWrapperReferenceFrom=Y] on X creates a hidden reference from the object group which Y belongs to to X's wrapper (Nothing happens if the object group doesn't contain any wrapper). That said, the current handling of wrapper reachability is still broken in some edge cases -- we need Oilpan to make it more correct.

[Kentaro Hara]

(yukishiino) Exposed JS getters/setters on almost all DOM attributes (except for Window's attributes and constructors). CL: https://codereview.chromium.org/1193793003/.

(yukishiino) Currently [Unforgeable] attributes are not inherited due to the IDL compiler bug. This hadn't been a big issue because the inheritance had been used only in a couple of attributes in Document (we worked around the issue by duplicating the [Unforgeable] attributes in all IDL files that inherit from Document). However, this approach no longer works because Event.isTrusted starts using [Unforgeable] (we cannot use the work-around since there are a lot of Events that inherit from Event.idl). We started implementing inheritance of [Unforgeable] attributes.

(yukishiino) Wrote up a document about the new cross-origin security model (https://docs.google.com/document/d/1hZlAf1G0mtButWRACBGsJfH0R93NAbK3PY4QVNKkRMo/edit). It's still not fully clear what needs to be fixed in the V8 side and in the V8 binding side to align with the Hixie's spec, but we decided to fix things incrementally from easier parts.

[Philip Jägenstedt]

An update on the Blink IDL spec sync: almost all of Source/core/ is now done, and overall progress is 469 of 902 .idl files, i.e. now over 50%!

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

[Jochen Eisinger]

On Tue, Jul 21, 2015 at 10:52 AM Philip Jägenstedt <phi...@opera.com> wrote:

An update on the Blink IDL spec sync: almost all of Source/core/ is now done, and overall progress is 469 of 902 .idl files, i.e. now over 50%!

On Tue, Jul 21, 2015 at 3:43 AM, Kentaro Hara <har...@chromium.org> wrote:

(yukishiino) Exposed JS getters/setters on almost all DOM attributes (except for Window's attributes and constructors). CL: https://codereview.chromium.org/1193793003/.

(yukishiino) Currently [Unforgeable] attributes are not inherited due to the IDL compiler bug. This hadn't been a big issue because the inheritance had been used only in a couple of attributes in Document (we worked around the issue by duplicating the [Unforgeable] attributes in all IDL files that inherit from Document). However, this approach no longer works because Event.isTrusted starts using [Unforgeable] (we cannot use the work-around since there are a lot of Events that inherit from Event.idl). We started implementing inheritance of [Unforgeable] attributes.

(yukishiino) Wrote up a document about the new cross-origin security model (https://docs.google.com/document/d/1hZlAf1G0mtButWRACBGsJfH0R93NAbK3PY4QVNKkRMo/edit). It's still not fully clear what needs to be fixed in the V8 side and in the V8 binding side to align with the Hixie's spec, but we decided to fix things incrementally from easier parts.

Note that's entirely unclear to me why we would need something as described in this doc to align our implementation with the spec...

[Yuki Shiino]

It turned out that I misunderstood that "unique per-tuple of (...)" in the spec memo meant that we have to implement === and != operators accordingly, but it was wrong.  I'll update my document.

Cheers,

Yuki Shiino

2015年7月21日火曜日 18時03分46秒 UTC+9 Jochen Eisinger:

[Kentaro Hara]

Hi

(yukishiino, haraken, jochen, verwaest, adamk) Discussed a lot about how the cross-origin security check should work for DOM attributes on Window and Location. yukishiino@ updated the document with corrected understandings (https://docs.google.com/document/d/1hZlAf1G0mtButWRACBGsJfH0R93NAbK3PY4QVNKkRMo/edit?pli=1#heading=h.4oqvz1ce5uv2).

(yukishiino) Implementing inheritance of [Unforgeable] attributes that expose JS getters/setters. This is needed for implementing Event.isTrusted correctly.

[Kentaro Hara]

Hi

(haraken) I was in Munich to discuss a bunch of stuff with the V8 team.

(haraken, yukishiino, jochen, verwaest) Discussed a way and reached a conclusion about what needs to done to implement the Hixie's spec of the cross-origin security checks (https://etherpad.mozilla.org/html5-cross-origin-objects).

(0) Motivation for this work: Correctness & inter-operability. We've migrated 99% of the DOM attributes to accessor-type properties (i.e., exposed JS getters/setters for the DOM attributes). The remaining DOM attributes are the ones on Window objects. We cannot migrate the Window's DOM attributes to accessor-type properties without fixing the following issues.

(1) we need to find correct home for DOM attributes/operations of a Window object (and other [Global] objects).

(2) We need to implement the following things in V8:

- A way to list up only whitelisted members when Object.getOwnPropertyNames(crossOriginWindow) gets called.

- A way to let the binding layer hook the access to a getter/setter of an accessor-type property. For example, in order to return a cross-origin-safe function for Object.getOwnPropertyDescriptor(crossOriginWindow, "self").get, the binding layer needs to be able to hook the getter and return a cross-origin-safe function properly.

(3) Once the above two issues are resolved, we can migrate Window's attributes to accessor-type properties. Then the "moving-DOM-attribute-to-prototype-chain" project will finish.

(haraken) Moved [Unforgeable] DOM attributes/operations from the inner global object to the Window wrapper.

(haraken) Noticed that we cannot move the values of [Replaceable] attributes to the Window wrapper without fixing (2) in the above.

(yukishiino) Supported inheritance of [Unforgeable] DOM attributes as accessor-type properties. This will be used by Event.isTrusted.

(yukishiino) Moved [OverrideBuiltin] DOM attributes to prototype chains.

(haraken) Landed a couple of CLs to simplify the handling of Window attributes.

[Kentaro Hara]

Hi

(yukishiino) Writing a design document to send an Intent-to-Implement-and-Ship for upcoming behavioral changes of Window's attributes.

(haraken) As the web evolves, it is getting harder and harder to implement a correct lifetime of V8 wrappers without introducing a memory leak around Blink <=> V8 references. ScriptPromise, ScriptValue, callback interfaces etc make the situation more complex. I'm going to write a design document that proposes a consistent way to design Blink <=> V8 object interactions without introducing memory leaks (i.e., "how to control DOM wrapper reachability without causing leaks").

[Kentaro Hara]

Hi

(yukishiino) Writing a design document that proposes changes on Window attributes. Added a layout test that described the changes (https://codereview.chromium.org/1282223003/).

(yukishiino) Fixed a bug 514775. <button onclick="incorrect javascript that cannot be compiled"> should not throw a JS exception when the onclick attribute is accessed.

(haraken) Trying to propose a way to remove all V8 leaks caused by Blink => V8 strong references. To that end, investigated existing Blink => V8 strong references and identified their problems. Writing a design document.

(shimadaa, natsukoa) Two interns joined our team. They will work on diffing Web IDLs between two Chromium releases so that web developers can easily understand Web API changes between Chromium releases. Our plan is to upload the diff to the Chromium dashboard page. You'll see the cool diff in the dashboard page in two months :)

--

Kentaro Hara, Tokyo, Japai

[Kentaro Hara]

Hi

(yukishiino) Sent an Intent-to-implement-and-ship to change the visibility of Window's members (https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/jlmsE3fDCNg). The Intent-to-implement-and-ship was approved.

(yukishiino) Creating a slide to explain our work in the next BrownBag.

(haraken) Wrote a design document to make Blink <=> V8 references collectable (https://docs.google.com/document/d/1gu7NwxuQ9fLWRRBjbH1MGKr7RZEx9ESRCZ3P4KwvP68/edit?ths=true). This will enable us to (1) completely remove V8 leaks that have been caused by Blink => V8 references and (2) remove all the complexity about wrapper lifetime management. We're planning to start the implementation in Q4.

(mlippautz, haraken) Previously majorGCPrologue/majorGCEpilogue had been called once per V8's major GC. However, it is no longer the case because an incremental marking can call majorGCPrologue/majorGCEpilogue multiple times to get a result of object grouping. Also, Blink objects are no longer dereferenced between majorGCPrologue and majorGCEpilogue. The dereferences happen in the next task (to reduce the atomic pause time of V8's major GC). According to these recent changes, we updated GC callbacks in the binding layer (https://codereview.chromium.org/1288683005).

[Kentaro Hara]

Hi

(yukishino) Did a presentation at BrownBag about interop efforts in the binding layer (https://docs.google.com/presentation/d/18Ap_EKEBu7nzDrlFM7FbCR4EgrNd3ryLabJUh-YvEwM/edit?pli=1#slide=id.g2480feb0_1_0). We're investing a lot of efforts on something very complicated around Window properties etc, but the slide explains why we're working on it.

(haraken) Looked at all Cr-Blink-Bindings bugs. Reduced the number from 200 to 125. Most of the bindings bugs are either of (1) feature requests, (2) tracking bugs, or (3) interop bugs. There are few crash bugs. (3) needs to be fixed, but it would be fair to say that the binding layer is in good shape :)

(bashi) Improved IDL dictionaries for new features in webrtc.

[Kentaro Hara]

Hi

(yukishiino) Made the default receiver of callback functions "undefined". See this CL for more details: https://codereview.chromium.org/1301423004/.

(yukishiino) Trying to move Window's methods from a prototype chain to an instance object (Note: Methods in [Global] objects need to be defined on an instance object, not a prototype chain). However, yukishiino@ hit a complex issue around Window.toString(). We decided to skip Window.toString() at the moment.

[Domenic Denicola]

Has there been any effort yet to move the window attributes to be getters instead of data properties? I remember hearing this was planned but wasn't sure if you'd started yet.

The reason I ask is that I am actually running in to very similar problems with Node.js. We have created "window like" objects using V8's SetNamedPropertyHandler and are noticing that all the accessor properties we define on this global object are now being exposed as data properties when you do `Object.getOwnPropertyDescriptor(globalProxy, "prop")`. `Object.defineProperty` does not work well on them either, just like in Chrome: Object.defineProperty(window, "frames", { get() { return 5; } }) will not change the result of Object.getOwnProperty(window, "frames"). So I was wondering if you'd started investigating fixes to this.

Happy to take this offline or to v8-users if you think that would be more appropriate.

[Kentaro Hara]

Has there been any effort yet to move the window attributes to be getters instead of data properties? I remember hearing this was planned but wasn't sure if you'd started yet.

That is exactly the goal of all the work yukishiino@ has been doing :) We still need a substantial amount of work to get Window's members right but are planning to fix it by the end of Q4. See yukishiino@'s slide (https://docs.google.com/presentation/d/18Ap_EKEBu7nzDrlFM7FbCR4EgrNd3ryLabJUh-YvEwM/edit#slide=id.g2480feb0_1_0) for more context.

[Domenic Denicola]

On Tuesday, September 8, 2015 at 2:37:12 AM UTC-4, Kentaro Hara wrote:

Has there been any effort yet to move the window attributes to be getters instead of data properties? I remember hearing this was planned but wasn't sure if you'd started yet.

That is exactly the goal of all the work yukishiino@ has been doing :) We still need a substantial amount of work to get Window's members right but are planning to fix it by the end of Q4. See yukishiino@'s slide (https://docs.google.com/presentation/d/18Ap_EKEBu7nzDrlFM7FbCR4EgrNd3ryLabJUh-YvEwM/edit#slide=id.g2480feb0_1_0) for more context.

Right, thanks! yukishiino@, do you have any thoughts in particular about the issue with V8's named property interceptor APIs only allowing data descriptors? Do you plan to change V8, or is there a different solution that I am missing?
 

[Yuki Shiino]

First of all, "named properties" are not DOM attributes.  They're special and different from attributes.

Attributes are defined as accessor-type properties by the spec, while named properties are defined as data-type properties by the spec.  So it's expected that named properties are data-type properties.

http://heycam.github.io/webidl/#named-properties-object-getownproperty

You cannot do [[DefineOwnProperty]] for named properties.  Exactly speaking, you can do, but it gets rejected.

http://heycam.github.io/webidl/#named-properties-object-defineownproperty

The problems you're facing seem no problem, they're the correct behaviors in terms of the Web IDL spec.

Cheers,

Yuki Shiino

[Kentaro Hara]

Hi

(yukishiino) Finished refactoring the IDL compiler so that we can easily customize the places where DOM methods are placed (i.e., on prototype, on instance, or/and on interface) (https://codereview.chromium.org/1322533002/). Will start moving Window's methods to a proper place.

(yukishiino) Fixed a really undeterministic crash associated with the timing between V8 GC and Oilpan's GC (https://codereview.chromium.org/1340513002/).

(haraken) Decided to schedule Oilpan's idle GC after V8's major GC. This seems to be a key (at least in V8 benchmarks) not to keep V8 contexts longer than expected (https://codereview.chromium.org/1334683002).

[Kentaro Hara]

Hi

(yukishiino) Moving EventHandlers and other Window's methods to the instance object (https://codereview.chromium.org/1333853002/). Addressing all test failures caused by the change. Fixed a browser_test (https://codereview.chromium.org/1333303002/).

(yukishiino) Addressed CFI errors in ScriptWrappable (https://codereview.chromium.org/1340513002/).

[Kentaro Hara]

Hi

(yukishiino) Finished fixing all tests that will be broken by moving EventHandlers and Window's methods to a Window's instance object. And landed the change. If you hit any compatibility issue, feel free to let us know.

(shimadaa; an intern) Landed a script that prints diff of IDL files between different Chrome revisions (CL, CL). We need to land a couple of more scripts to make it workable.

[Kentaro Hara]

Hi

(yukishiino) Preparing to make non-whitelisted attributes accessor-type JS properties (https://codereview.chromium.org/1380503002/).

(yukishiino) Refactoring code around method installation (related to per-member static [Exposed], etc) (https://codereview.chromium.org/1372373002/).

(haraken, tasak) Brainstorming the applicability of script-disabled rendering for emerging markets. We suspended the project one year ago because it's hard to guarantee 100% correctness. The situation has been changing, and we started rethinking about the script-disabled rendering in the context of user agent intervention.

(haraken, yukishiino, bashi, tasak) Finalized Q4 plans. The main goal is to make the behavior of Window objects 100% interoperable.

[Kentaro Hara]

Hi

(yukishiino) Implemented the named properties object for window. Now the prototype chain of the window looks like this:

window.__proto__ => Window.prototype

window.__proto__.__proto__ => WindowProperties object  (<---- We added this one.)

window.__proto__.__proto__.__proto__ => EventTarget.prototype

(yukishiino) Once we make the window implementation spec-conformant (and interoperable with other browsers), we can no longer create a fake window object by Object.create(window). We found that distiller is using the fake window object. So we removed it.

(yukishiino) Supported per-static member [Exposed] IDL attribute.

(haraken) Writing a design document about script-disabled rendering.

[Kentaro Hara]

Hi

(yukishiino) Discussing with the V8 team to fix the remaining interop issues on Window and Location objects. Toon proposed an interesting idea called "LazyAccessorPair". It would be a substantial amount of work to implement it in V8 but it seems a right way to go. Still discussing.

(tasak) Creating a prototype of script-disabled rendering (i.e., render & display a script-disabled view => render a script-enabled view in background => once it's complete, switch to the script-enabled view). tasak@ is hacking code of Chrome's prerendering and creating a demo.

(haraken) Wrote a design document of the script-disabled rendering. I'll share the document once the demo is ready.

(vivekg) Moving hasPendingAcitivity from ActiveDOMObject to ScriptWrappable. Currently we have to make a bunch of DOM objects ActiveDOMObjects just because the DOM objects has pending activities. This adds a lot of overhead to the LifecycleNotifier because the notifier needs to keep track of the list of ActiveDOMObjects. hasPendingActivity should be moved to ScriptWrappable and we should reduce the number of ActiveDOMObjects in Blink.

(haraken) I'll visit Munich next week to discuss a bunch of Memory & Binding stuff with the V8 team.