Closed Bug 939509 Opened 8 years ago Closed 7 years ago

File constuctor ignores lastModifiedDate


(Core :: DOM: Core & HTML, defect)

28 Branch
Not set



Tracking Status
firefox38 --- fixed


(Reporter: costan, Unassigned)




(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.14 Safari/537.36

Steps to reproduce:

Call the File constructor with a lastModifiedDate set to a Date that is not current, e.g.

new File([], "name.txt", {lastModifiedDate: new Date( - 86400 * 1000)});

Actual results:

The created File instance's lastModifiedDate is always the current time.

A test case showing this:

Expected results:

Per the File API spec[1]:
1) Since I'm passing a Date in the lastModifiedDate property, that is the value that should should be returned by the lastModifiedDate property. ( phrase 1)
2) If I wouldn't have passed a lastModifiedDate, the property should have been a Date that represents the moment the File was constructed. ( phrase 2)

I tried this out in Firefox nightly because I wanted to see how you implemented lastModifiedDate. in the File API spec is actually 7.1 step 3.3, and it is confusing me. It says

"If the lastModifiedDate member is provided, let d be set to the lastModifiedDate dictionary member. If it is not provided, set d to the current date and time (which is the equivalent of [ECMA-262])"

The fact that it says "equivalent of" instead of "equivalent of new Date()" makes me think that not having a lastModifiedDate should be equivalent to new File(..., {..., lastModifiedDate:}).

But this means that the File constructor should accept accept Date instances, as well as numbers for the lastModifiedDate property, so the code above can work.

Can you please either help me figure out where I should file a spec bug, or tell me what you implement? I'm implementing this in Blink, and I'd like to be on the same page.

Thank you!
Component: General → DOM
We just don't implement the "lastModifiedDate" member of the init dictionary, as far as I can tell.  I don't know whether we're implementing an older draft or what, but we support a "type" member in that dictionary and an "endings" member; that's it.

Note that I've provided feedback in email to the spec editor here that using Date in the dictionary is probably wrong; instead it should use long long representing a number of milliseconds since the epoch; that way passing either a Date object or or any other millisecond timestamp would work correcty.  I don't know whether the spec editor plans to do anything with that feedback; it might be worth filing a spec bug too.
Ever confirmed: true
The latest ED renamed the property lastModified and changed its WebIDL type to long long, so it takes both numbers and Date instances (via conversion).

Chrome implements the latest ED. The implementation is gated by the experimental Web Platform features flag, and we're waiting for the ED to be promoted to TR before we consider making it stable.

I hope this helps!
Attached patch date.patchSplinter Review
Attachment #8560489 - Flags: review?(bzbarsky)
With this patch, I added the support of lastModified in the dictionary for the File constructor. I don't touch the chrome-only constructors.
Comment on attachment 8560489 [details] [diff] [review]

>+  MOZ_CRASH("SetLasTModified of a real file is not allowed!");

s/TM/tM/  ?

Attachment #8560489 - Flags: review?(bzbarsky) → review+
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.