location.href claimed to be missing from Chrome, but is there

[foolip]

In Chrome 62 on Windows 10 in BrowserStack, Object.getOwnPropertyNames(location) includes href. However, it's claimed to be missing in the confluence data.

[foolip]

Apparently Object.getOwnPropertyNames(Location.prototype) doesn't include "href", or anything other than "constructor".

[mdittmer]

Object.getOwnPropertyDescriptor(location, 'href') in Chrome satisfies the definition of a constant so it is excluded.

Does the spec specify whether or not location instances should have a property descriptor with a value?

[foolip]

Spec is at https://html.spec.whatwg.org/multipage/history.html#the-location-interface and uses [Unforgeable], which per https://heycam.github.io/webidl/#Unforgeable means that "the property will be non-configurable and will exist as an own property on the object itself rather than on its prototype."

But, I think that ought to still be a getter/setter pair rather than a data property. Can you check if the property descriptor for location.href is different in other browsers? I would not be too surprised if this were a Blink bindings bug, since it's pretty elaborate in location.idl: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/frame/location.idl?l=58&rcl=39be578626f8521661c3a4a606ccead8eea0bb2c

[mdittmer]

Interesting. So no specification of getter vs. value, which is what we are using to detect constants.

On May 15, 2018 3:54 PM, "Philip Jägenstedt" notifications@github.com wrote:

Spec is at https://html.spec.whatwg.org/multipage/history.html#the-location-interface and uses [Unforgeable], which per https://heycam.github.io/webidl/#Unforgeable means that "the property will be non-configurable and will exist as an own property on the object itself rather than on its prototype."

But, I think that ought to still be a getter/setter pair rather than a data property. Can you check if the property descriptor for location.href is different in other browsers? I would not be too surprised if this were a Blink bindings bug, since it's pretty elaborate in location.idl: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/frame/location.idl?l=58&rcl=39be578626f8521661c3a4a606ccead8eea0bb2c

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/GoogleChromeLabs/confluence/issues/259#issuecomment-389292684, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsWSPFxH2jxwNJWnQlFBxnbumstBHO9ks5tyzJmgaJpZM4Ro34x .

[foolip]

I'm pretty sure it should be a getter, not a data property. If you search for "data propert" and "[[Value]]" in the Web IDL spec I think that's everything involving data properties, and constants are included there. https://heycam.github.io/webidl/#namespace-object is too, so I wonder if this heuristic is going to be increasingly wrong.

[bzbarsky]

@mdittmer if href is not an accessor property that's definitely a bindings bug in Blink.

[bzbarsky]

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=845493 on that.