All users were logged out of Bugzilla on October 13th, 2018

Object.defineProperty is using === rather than SameValue

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
8 years ago
7 years ago

People

(Reporter: erights, Unassigned)

Tracking

Other Branch
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
> Object.getOwnPropertyDescriptor(window, 'NaN').toSource()
  ({value:NaN, writable:false, enumerable:false, configurable:false})

  > Object.defineProperty(window, 'NaN', {value: NaN})
  TypeError: can't redefine non-configurable property 'NaN'

By SameValue, this is an allowed harmless setting of the property to its current state. But if Object.defineProperty is using === instead, it would think we're trying to make a forbidden change.


on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b5pre) Gecko/20100827 Minefield/4.0b5pre

Comment 1

8 years ago
This isn't the absence of use of SameValue, because the analog works fine in the shell: I suspect a browser-global-window-specific quirk.
(Reporter)

Comment 2

8 years ago
Thanks for the quick response. Yes, the bug does not occur for non-window objects. Also, the bug does also occur on window for 'Infinity' and 'undefined'.
(Reporter)

Comment 3

8 years ago
And only when using the names 'NaN', 'Infinity', and 'undefined'. Doing redundant defineProperty on window with these values by any other name smells much sweeter.
(Reporter)

Comment 4

8 years ago
Shouldn't this be closed as invalid?
(Reporter)

Updated

8 years ago
Summary: Object.defineProperty is using === rather than SaveValue → Object.defineProperty is using === rather than SameValue
(Reporter)

Comment 5

8 years ago
Should this bug be closed?

Comment 6

8 years ago
It seems like a valid bug to me.  I doubt WebIDL or something or other would end up making this not work somehow (a [[DefineProperty]] hook on window objects defined just so in order to produce this behavior?).  In the absence of any other direction this seems like a valid bug to me, just reasonably low priority as you basically have to try to trigger it in order to be surprised, and the only thing you'd expect the try to get you would be a no-op, so there's no point in trying anyway.
(Reporter)

Comment 7

8 years ago
I cannot reproduce the reported buggy behavior on FF4.0.1. Am I missing something?
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.