Binding team snippets

[Kentaro Hara]

This Week:

(haraken, tasak, bashi, kinuko, tkent) Proposed the Blink componentization and discussed a lot of things (e.g., removing the WTF namespace, relationships between wtf/ and base/, future dependency model in Blink, where Oilpan should be located etc). A lot of discussions are on-going in blink-dev & offline.

(tasak, thakis, hans) Landed the core-modules componentization (but reverted)! Addressed a couple of build issues caused by the core-modules componentization.

(yukishiino) Made the Location interface [Unforgeable] per the spec.

(yukishiino) Studying the attribute lookup algorithm of the Window interface. Studying how the cross-origin security check should work on the Window interface. They are complicated. It will take more time to understand & fix what is broken in the current implementation, but this is important to correctly expose JS getters/setters on Window's DOM attributes.

(bashi) Finished replacing V8 APIs in bindings/ with the Maybe version of the V8 APIs. This work fixed a lot of potential crashes in ServiceWorkers. In fact, we were able to close several crash bugs in ServiceWorkers and IndexedDB!

(bashi) Supported 'any' type in IDL dictionary. Replacing [InitializedByEventConstructor]s with EventInit per the spec. The goal is to make all IDL dictionaries in Blink conformant with the spec and remove customized dictionary implementations from Blink.

(bashi, jochen, haraken) We noticed that it is unsafe to use Object::Set in bindings/, because the setter can be customized in user's JS and thus any arbitrary JS can run during Object::Set. On the other hand, we cannot simply replace the Object::Set with Object::ForceSet, because the implementation of Object::ForceSet is tricky in a couple of ways in V8. What we really need is a V8 API for [[DefineOwnProperty]]. Jochen implemented it for us :)

Next Week:

(haraken, tasak, bashi, kinuko, tkent) More discussions about the componentization plan.

(tasak) Reland the core-modules componentization.

(bashi) Replace Object::Set in bindings/ with the V8 API for [[DefineOwnProperty]].

(bashi) Replace V8 APIs in gin with the Maybe version.

(yukishiino) Understand the cross-origin security checks & Window attribute lookups.

(yukishiino) Expose JS getters/setters on [Unforgeable] DOM attributes.

--

Kentaro Hara, Tokyo, Japan

[Philip Jägenstedt]

An update on the IDL spec sync: Getting through the SVG interfaces bumped the progress to 301 of 817 interfaces, which means it's more than 1/3rd done. If anyone sees FIXME or TODO(philipj) in their favorite IDL files, please help get rid of them by aligning with the spec or having the spec changed!

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

[Kentaro Hara]

An update on the IDL spec sync: Getting through the SVG interfaces bumped the progress to 301 of 817 interfaces, which means it's more than 1/3rd done. If anyone sees FIXME or TODO(philipj) in their favorite IDL files, please help get rid of them by aligning with the spec or having the spec changed!

(BTW, this kind of follow-up is very helpful to understand what's going on around us :-)

[Kentaro Hara]

This Week:

(haraken, kinuko, phillipj, bashi, tasak and others) We had a lot of discussions about the componentization. haraken@ wrapped up the long discussions in this document (https://docs.google.com/document/d/1gwQ1qn3Qx1U_xm9BbwIsJz0GP_05KUXVHhk3PxeNuSw/edit). haraken@ scanned files in platform/ and web/ and counted the number of proxy classes that will be removed by the componentization (https://docs.google.com/spreadsheets/d/19lWCtLl87fBH0LFsN00UNkfX_NltrYAA8yshYWc53_0/edit#gid=971383183). About 100. However, given the scale of the relayering, I'm not sure when to start the relayering of the Web classes.

(yukishiino) Investigated the visibility issues of JS global variables and [Global] DOM attributes. Wrote up a document to summarize the current implementation & the expected behavior per the spec (https://docs.google.com/document/d/1mJSkyEroEkzTcb0OpVc6TwKkIEWqSeHu6QLcWwAy8_M/edit)

(yukishiino) Implemented [LenientThis] per the spec. This is necessary to fix compatibility issues caused by moving GlobalEventHandlers.onmouseenter, GlobalEventHandlers.onmouseleave and Document.onreadystatechange to prototype chains.

(yukishiino) Fixed a security hole of static operations that return DOM wrappers.

(yukishiino) Investigated how EventTarget.dispatchEvent and Event.isTrusted work. Discussed how to support it in Blink.

(bashi) Finally finished replacing all Blink-specific EventInit implementations with IDL dictionaries per the spec. This removed a lot of code (i.e., [EventConstructor] and [InitializedByEventConstructor] are gone!)

(bashi) Finished replacing V8 APIs in gin and net/proxy/ with the Maybe version. Started working on extensions/renderer/.

(bashi) Replacing Set/ForceSet in V8 bindings with CreateDataProperty/DefineOwnProperty to make the behavior align with the spec.

Next Week:

(yukishiino) Make the visibility of JS global variables and [Global] DOM attributes correct.

(bashi) Replace V8 APIs in extensions/renderer/ with the Maybe version.

[Domenic Denicola]

+bz

From: har...@google.com [mailto:har...@google.com] On Behalf Of Kentaro Hara

> (yukishiino) Investigated the visibility issues of JS global variables and [Global] DOM attributes. Wrote up a document to summarize the current implementation & the expected behavior per the spec (https://docs.google.com/document/d/1mJSkyEroEkzTcb0OpVc6TwKkIEWqSeHu6QLcWwAy8_M/edit)

Boris, I know you have been looking into this area and making changes around some of the crazier or less-specified edge cases (e.g. [1], [2], probably more I am forgetting). Would you be willing to take a look at the doc?

[1]: https://github.com/heycam/webidl/pull/48
[2]: https://github.com/heycam/webidl/pull/45

> (bashi) Finally finished replacing all Blink-specific EventInit implementations with IDL dictionaries per the spec. This removed a lot of code (i.e., [EventConstructor] and [InitializedByEventConstructor] are gone!)

This is really exciting news! Can we delete them from https://www.chromium.org/blink/webidl/blink-idl-extended-attributes ?

[Kentaro Hara]

Done.

[Boris Zbarsky]

On 6/5/15 11:19 AM, Domenic Denicola wrote:
> Boris, I know you have been looking into this area and making changes around some of the crazier or less-specified edge cases (e.g. [1], [2], probably more I am forgetting). Would you be willing to take a look at the doc?

Sure. A few comments:

1) I'm not sure whether the "The global object and the prototype chain
of Window interface" section is trying to describe the current Blink
implementation or the spec, but per spec the prototype chain of window
looks like this:

window -> Window.prototype -> named properties object ->
EventTarget.prototype -> Object.prototype

Window's named properties go on the "named properties object" per spec.
The only property that appears by default on Window.prototype is
"constructor". This should probably be added to the "Things we need to
fix" bit.

2) In the "What are visible and what are shadowed?" section, I assume
"JavaScript global variable creation" refers to "var" at toplevel in a
script, not to ES built-ins. If so, those variables are created after
the Window interface members, as the document says, because they're only
created the first time a toplevel script is run, whereas the global
object has to be created before you start running any scripts against
it. At least that's the only sane way to do it, imo.

3) "var addEventListener" is not quite identical to
"this.addEventListener = undefined" because the former creates a
non-configurable property. But apart from that, I agree with the two
case descriptions in the "What are visible and what are shadowed?" section.

4) Mostly agreed on the "Conclusion" section, with the caveat for
comment #1 above and the general understanding that this is a
qualitative description that glosses over details. For example,
deleting an interface property from window does not suddenly "unshadow"
a declared var that was declared before the delete, because the var
declaration was ignored due to the property already existing. But a var
declaration in a script that runs after the delete will define a global
variable.

Please do let me know if you run into more spec issues (esp. for the
named properties object) as you do this. I've tried to iron them out,
but the details of some edge cases here are ... complicated.

-Boris

[Yuki Shiino]

Thanks for the comments.  I've got better understanding, especially for the named properties object.

For 1), I tried to understand the spec and describe what the spec requires.  I agree that we should add "WindowProperties" in the prototype chain, not only for Window but also for all interfaces which support named properties.  I also found that Blink's class name is wrong.  It must be "WindowPrototype" for the Window's prototype object (currently it's "Window").

For 2) to 4), completely agreed.  I'll add notes to clarify things.

The purpose of the doc is to get correct understanding about the spec in order to make Blink better conform to the spec.  I don't see any issue of the spec.  Lack of WindowProperties just showed lack of my understanding.

Again, thanks for the comments.

Yuki Shiino


2015年6月6日土曜日 0時38分28秒 UTC+9 Boris Zbarsky:

[Boris Zbarsky]

On 6/8/15 9:05 AM, Yuki Shiino wrote:
> For 1), I tried to understand the spec and describe what the spec
> requires. I agree that we should add "WindowProperties" in the
> prototype chain, not only for Window but also for all interfaces which
> support named properties.

No, for most objects with named properties those live directly on the
object. A global with named properties is special in having this
separate singleton object for the named props on the proto chain.

> I also found that Blink's class name is
> wrong. It must be "WindowPrototype" for the Window's prototype object
> (currently it's "Window").

Note the discussion in https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244

-Boris

[Yuki Shiino]

Thanks for guiding us to the right path.

2015-06-09 0:12 GMT+09:00 Boris Zbarsky <bzba...@mozilla.com>:

On 6/8/15 9:05 AM, Yuki Shiino wrote:

For 1), I tried to understand the spec and describe what the spec
requires.  I agree that we should add "WindowProperties" in the
prototype chain, not only for Window but also for all interfaces which
support named properties.

No, for most objects with named properties those live directly on the object.  A global with named properties is special in having this separate singleton object for the named props on the proto chain.

Ah!  Got it.  Thanks for correcting me.  I read the spec again, and got it.

I also found that Blink's class name is
wrong.  It must be "WindowPrototype" for the Window's prototype object
(currently it's "Window").

Note the discussion in https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244

-Boris

I see.  Then, we'll go with "[object Window]" for Window's prototype and see what kind of issues happen.  Thanks for the pointer.

Cheers,

Yuki Shiino