Intent to Implement and Ship: Visibility change of Window's members

[Yuki Shiino]

Contact emails

yukis...@chromium.org, har...@chromium.org

Spec

4.3.6. [Global] and [PrimaryGlobal]

http://heycam.github.io/webidl/#Global

4.5.5. Named properties object

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

4.7.1. Indexed and named properties

http://heycam.github.io/webidl/#indexed-and-named-properties

Summary

Fix Window's members' visibility.

Motivation

Blink's implementation and behavior about Window's members are unique among FF, IE and Safari.  It differs from the spec.  Let's fix it and align to the behavior of FF, IE, Safari and the spec.

Design doc

https://docs.google.com/document/d/1t5nGcSNaABBBoPNCkDHheCifU1jBu7_AZmjhaXU-O8I/edit?usp=sharing

Proposed changes

1. Named child browsing contexts should NOT shadow Window's other members.

before: Named child browsing contexts have the highest priority when looking for a name.

after: Named child browsing contexts have the same priority as other named properties.

2. Event handlers on 'window' (window.onxxx) should be placed on "window" instance object.

before: onxxx are placed at Window.prototype.onxxx

after: onxxx are placed at window.onxxx (window.hasOwnProperty('onxxx') returns true.)

3. Operations (methods) should be placed on "window" instance object.

before: alert function is placed at Window.prototype.alert

after: alert function is placed at window.alert (window.hasOwnProperty('alert') returns true.)

4. Introduce the named properties object for Window (i.e. WindowProperties) to the prototype chain of Window.

Compatibility Risk

As expected results of the changes, users will see the following behavioral changes.

1. Named child browsing contexts

    iframe = document.createElement('iframe')

    iframe.name = 'alert'

    document.body.appendChild(iframe)

Before: 'window.alert' returns iframe.contentWindow object.

After: 'window.alert' returns the built-in alert function.

2. Event handlers

    var onclick = function() { console.log('clicked'); }

Before: A global variable 'onclick' is created.  'onclick' attribute is not changed.  So, when clicked, no message appears on the console.

After: A global variable 'onclick' is NOT created because 'window' already has 'onclick' member on the instance object.  'onclick' attribute is updated.  So, when clicked, "clicked" message appears on the console.

3. Operations (methods)

No notable change compared to 2. Event handlers.  Technically the same thing happens, however, assignments to operations are simple assignment unlike attributes, thus users may not recognize a change unless they directly access to 'Window.prototype.methodName'.

4. WindowProperties

Before: window.__proto__.__proto__ === EventTarget.prototype

After: window.__proto__.__proto__ === the named properties object of Window (i.e. WindowProperties)

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

Change 1 to 3 may be seen only when web developers use conflicting global variable names with Window's members (e.g. alert, onclick, etc.)

Since FF, IE and Safari already implemented the spec correctly, no compatibility risk is expected when compared to other browsers.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

http://crbug.com/516274

Link to entry on the feature dashboard

No entry.  Because the changes do not affect developers as long as developers do not use global variables with conflicting names.

[PhistucK]

On Mon, Aug 17, 2015 at 11:27 AM, Yuki Shiino <yukis...@chromium.org> wrote:

Link to entry on the feature dashboard

No entry.  Because the changes do not affect developers as long as developers do not use global variables with conflicting names.

​I prefer that you create one regardless of the probability of the situation. This makes (even more) sure the beta blog post mentions it.

I understand you did not create some sort of a use counter for all of these things (some are easier, like the iFrame name that shadows a method, some are harder)... Unfortunately, there is enough content ​that is intended only for Chrome, so breakages are not at all impossible. I hope the various early release channels will help here.

☆PhistucK

[Philip Jägenstedt]

LGTM, I love this kind of stuff :)

An odd thing about the current setup is the named child browsing context and element id "fallbacks" are not in the same place:

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3599

From the design doc it looks like both of these cases will end up in the [WindowProperties] bucket, which seems nice.

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

[Jochen Eisinger]

lgtm2

[Alex Komoroske]

On Mon, Aug 17, 2015 at 1:35 AM, PhistucK <phis...@gmail.com> wrote:

On Mon, Aug 17, 2015 at 11:27 AM, Yuki Shiino <yukis...@chromium.org> wrote:

Link to entry on the feature dashboard

No entry.  Because the changes do not affect developers as long as developers do not use global variables with conflicting names.

​I prefer that you create one regardless of the probability of the situation. This makes (even more) sure the beta blog post mentions it.

I agree, when in doubt it's best to create a chromestatus.com entry. 

[Rick Byers]

LGTM3 - thanks for improving interoperability!

I'm shocked that I hadn't heard of the "var onclick = ..." bug before (I guess that's a good thing, issues in practice must have been rare)...

I assume these bugs were introduced as part of the DOM prototype chain work, is that right?  I.e. they didn't exist in Chrome prior to M43 or so?  If I'm wrong and they're really long-standing bugs in chromium then we might want to prepare more for some interop issues with Chrome-specific scenarios (Chrome apps, possibly Android WebView, etc.).

Rick

[Kentaro Hara]

On Mon, Aug 17, 2015 at 11:10 PM, Rick Byers <rby...@chromium.org> wrote:

LGTM3 - thanks for improving interoperability!

I'm shocked that I hadn't heard of the "var onclick = ..." bug before (I guess that's a good thing, issues in practice must have been rare)...

I assume these bugs were introduced as part of the DOM prototype chain work, is that right?  I.e. they didn't exist in Chrome prior to M43 or so?  If I'm wrong and they're really long-standing bugs in chromium then we might want to prepare more for some interop issues with Chrome-specific scenarios (Chrome apps, possibly Android WebView, etc.).

These are long-standing bugs in Chromium and are not related to the DOM prototype chain work :-/

Just to clarify: We have a bunch of interop bugs about Window attributes/methods. Some of the bugs are blocking us from exposing JS getters/setters on Window attributes (Note: Due to the bugs, we have _not_ yet exposed JS getters/setters on Window attributes). Other bugs are long-standing ones and not related to exposing JS getters/setters. This intent-to-implement-and-ship is for the latter bugs. For the former bugs, we're planning to write another intent-to-implement-and-ship.

Rick

On Mon, Aug 17, 2015 at 9:20 AM, Alex Komoroske <komo...@chromium.org> wrote:

On Mon, Aug 17, 2015 at 1:35 AM, PhistucK <phis...@gmail.com> wrote:

On Mon, Aug 17, 2015 at 11:27 AM, Yuki Shiino <yukis...@chromium.org> wrote:

Link to entry on the feature dashboard

No entry.  Because the changes do not affect developers as long as developers do not use global variables with conflicting names.

​I prefer that you create one regardless of the probability of the situation. This makes (even more) sure the beta blog post mentions it.

I agree, when in doubt it's best to create a chromestatus.com entry. 

I understand you did not create some sort of a use counter for all of these things (some are easier, like the iFrame name that shadows a method, some are harder)... Unfortunately, there is enough content ​that is intended only for Chrome, so breakages are not at all impossible. I hope the various early release channels will help here.

☆PhistucK

--

Kentaro Hara, Tokyo, Japan

[Rick Byers]

On Mon, Aug 17, 2015 at 10:44 AM, Kentaro Hara <har...@chromium.org> wrote:

On Mon, Aug 17, 2015 at 11:10 PM, Rick Byers <rby...@chromium.org> wrote:

LGTM3 - thanks for improving interoperability!

I'm shocked that I hadn't heard of the "var onclick = ..." bug before (I guess that's a good thing, issues in practice must have been rare)...

I assume these bugs were introduced as part of the DOM prototype chain work, is that right?  I.e. they didn't exist in Chrome prior to M43 or so?  If I'm wrong and they're really long-standing bugs in chromium then we might want to prepare more for some interop issues with Chrome-specific scenarios (Chrome apps, possibly Android WebView, etc.).

These are long-standing bugs in Chromium and are not related to the DOM prototype chain work :-/

Oh!  Well I'm glad to hear we didn't regress these :-).  What about the old Android WebView - it didn't have these bugs too, did it?  If not, then presumably our chance of breaking webview apps is low (since most would still need to be written to work with pre-KitKat devices).  If the old WebView did somehow have the same bugs (eg. what bindings logic did that build of WebKit use?), then we might need to add a compat-hack to avoid breaking Android apps.

Chrome apps tend not to be a big risk IMHO because most share code with websites which are cross-browser.

So probably the biggest risk is still just sites with lots of UA-specific code.  Have you verified that our new behavior matches MS Edge (which uses a Chrome user-agent string)?  If so then the compat risk should be low (or we probably would have already heard from our friends at MS that our bug was causing compat pain for them).  But if Edge does have any of these quirks then it probably indicates there are sites in the wild relying on the behavior when the UA contains 'Chrome'.

Other than that, I don't have any concrete advice other than to watch out for reports of regressions and be prepared to temporarily flip this off before it hits stable if there's evidence that we need some more time to properly manage the transition.

[Yuki Shiino]

I've created an entry at chromestatus.com.

https://www.chromestatus.com/features/5764672187793408

Will check MS Edge's behavior.  (I checked with IE, but not Edge yet.)

To Philip, yes, all named properties, including named child browsing contexts, will be served at WindowProperties object.

[Yuki Shiino]

It turned out that I checked the behavior with IE 11 (Edge engine).  I don't know well about what difference between Edge on Win10 and IE 11 (Edge engine) on Win7.  I'm now preparing Win10 environment.

[Yuki Shiino]

Sorry for the late response.

rbyers> What about the old Android WebView - it didn't have these bugs too, did it?  If not, then presumably our chance of breaking webview apps is low (since most would still need to be written to work with pre-KitKat devices).  If the old WebView did somehow have the same bugs (eg. what bindings logic did that build of WebKit use?), then we might need to add a compat-hack to avoid breaking Android apps.

I've tested with "Browser" on Android 4.3.1 (pre-KitKat) on the emulator, assuming it behaves the same as Android WebView.  The behavior is the same as the current Blink.  I mean that "Browser" has the same bugs.

I understand your concerns.  However, I think users won't see any difference unless developers write insane JS code such like naming an iframe "alert".  Let us move forward and see what will happen.

rbyers> Have you verified that our new behavior matches MS Edge (which uses a Chrome user-agent string)?

I've tested with Edge 20 on Windows 10.  The results are the same as IE11 on Win 7.  I've updated the doc accordingly.

Having said that, I've seen some of improvements in Edge.

- EventTarget interface is now supported.

- window.__proto__.__proto__ == EventTarget.prototype

- "id" attribute is correctly placed at Element.prototype.

  (On IE11, "id" is placed at HTMLElement.prototype.)

[PhistucK]

At some point, the stock Android browser started using V8 (it used JavaScriptCore prior to that). I assume this is when the issue started appearing in the stock browser (as well as WebView). It is using V8 since Froyo (2.2).

Reference - https://en.wikipedia.org/wiki/Android_version_history#Android_2.2.E2.80.932.2.3_Froyo_.28API_level_8.29

☆PhistucK

[Mikhail Naganov]

WebView person here, some comments.

> rbyers> What about the old Android WebView - it didn't have these bugs too, did it?  If not, then presumably our chance of breaking webview apps is low (since most would still need to be written to work with pre-KitKat devices).  If the old WebView did somehow have the same bugs (eg. what bindings logic did that build of WebKit use?), then we might need to add a compat-hack to avoid breaking Android apps.

> I've tested with "Browser" on Android 4.3.1 (pre-KitKat) on the emulator, assuming it behaves the same as Android WebView.  The behavior is the same as the current Blink.  I mean that "Browser" has the same bugs.

Yes, testing with Browser on 4.3.1 (JellyBean MR2) is the right way -- it uses WebView, and we use JB-MR2 as a compatibility reference for the new Chromium-based WebView. The old one was indeed based on WebKit + V8 at that time.

> I understand your concerns.  However, I think users won't see any difference unless developers write insane JS code such like naming an iframe "alert".  Let us move forward and see what will happen.

Usually problems occur if some popular JS library was relying on the old behavior and is got broken by the changes. The problem with mobile apps is that they do not update their third-party libraries as often as real web apps do.

I think you can coordinate shipping your change with us, we do alpha testing with popular apps, so can detect problems early. I've added our label to your launch tracking bug.

[Yuki Shiino]

Thank you, Mikhail.

How can we coordinate with you guys?  Committing CLs with BUG= line should notify you guys.  Is it enough?  Or should we do something else?  We can cc with you guys when we send CLs for review, if you want.

Cheers,

Yuki Shiino

[Mikhail Naganov]

Yes, that should be enough, thanks!

[Rick Byers]

Thanks guys.  I agree the WebView-specific risk sounds low and coordinating with the WebView team to watch for any specific issues seems like adequate mitigation.  Thanks!

Rick