confluence
confluence copied to clipboard
GoogleChromeLabs
location.href claimed to be missing from Chrome, but is there
In Chrome 62 on Windows 10 in BrowserStack, Object.getOwnPropertyNames(location) includes href. However, it's claimed to be missing in the confluence data.
Apparently Object.getOwnPropertyNames(Location.prototype) doesn't include "href", or anything other than "constructor".
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?
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
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" [email protected] 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 .
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.
@mdittmer if href is not an accessor property that's definitely a bindings bug in Blink.
I filed https://bugs.chromium.org/p/chromium/issues/detail?id=845493 on that.