RESOLVED INVALID 49589
DOMTimeStamp needs to be bound to Date object in ECMAScript 
https://bugs.webkit.org/show_bug.cgi?id=49589
Summary DOMTimeStamp needs to be bound to Date object in ECMAScript
John Knottenbelt
Reported 2010-11-16 03:11:38 PST
In mac WebKit, DOMTimeStamp is currently bound to an integer. It should be bound to a Date object as per the w3c spec: http://www.w3.org/TR/DOM-Level-3-Core/core.html#Core-DOMTimeStamp
Attachments
Patch (4.57 KB, patch)
2010-11-16 07:54 PST, John Knottenbelt 		sam: review-
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
John Knottenbelt
Comment 1 2010-11-16 07:54:43 PST
Created attachment 73994 [details] Patch
Sam Weinig
Comment 2 2010-11-16 09:42:02 PST
Do any other browsers do this? If not, it seems like this could be a compat issue.
John Knottenbelt
Comment 3 2010-11-17 06:58:30 PST
Out of Opera, Firefox, Safari, and Chromium, it seems that right now only Chromium binds it to a Date object. I tried to check on IE, but my test script failed as the onload event did not have a timeStamp field. The ECMAScript 262 specification for Date says that the valueOf() method of Date should return "the Number, which is the time value". This means that code that works with the DOMTimeStamp as if it were a number should continue to work (even if it is a Date instance). I use this fact in my test https://bugs.webkit.org/show_bug.cgi?id=48518 where I check that Geoposition timestamps are well-formed. Since this change affects only Mac WebKit, it would be great if you could suggest next steps on this issue.
Sam Weinig
Comment 4 2010-11-21 17:04:51 PST
(In reply to comment #3) > Out of Opera, Firefox, Safari, and Chromium, it seems that right now only Chromium binds it to a Date object. > > I tried to check on IE, but my test script failed as the onload event did not have a timeStamp field. > > The ECMAScript 262 specification for Date says that the valueOf() method of Date should return "the Number, which is the time value". This means that code that works with the DOMTimeStamp as if it were a number should continue to work (even if it is a Date instance). I use this fact in my test https://bugs.webkit.org/show_bug.cgi?id=48518 where I check that Geoposition timestamps are well-formed. > > Since this change affects only Mac WebKit, it would be great if you could suggest next steps on this issue. I don't understand why this only affects Mac WebKit, it seems like it should effect all ports of WebKit that use the WebKit JS engine, JavaScriptCore. If only chromium has this behavior, I suggest moving chromium to match other browsers.
John Knottenbelt
Comment 5 2010-11-22 06:18:32 PST
Sam, you are correct, I should have said JSC instead of WebKit mac.
Sam Weinig
Comment 6 2010-11-22 13:54:35 PST
Ok, I am going to mark this bug as INVALID then.
John Knottenbelt
Comment 7 2010-11-23 03:06:43 PST
(In reply to comment #6) > Ok, I am going to mark this bug as INVALID then. Agreed. I've filed a new bug to change the V8 bindings for DOMTimeStamp from Date object to Number, with rationale in the bug description. https://bugs.webkit.org/show_bug.cgi?id=49963
Note You need to log in before you can comment on or make changes to this bug.