New issue
Advanced search Search tips

Issue 692728 link

Starred by 5 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 674593


Show other hotlists

Hotlists containing this issue:
Non-Standard-IDL


Sign in to add a comment

Remove non-standard (obsolete) API File#lastModifiedDate in favor of current File#lastModified

Project Member Reported by lunalu@chromium.org, Feb 15 2017

Issue description

It is commented as a non-standard API. Currently it is not in Gecko or WebKit. Should we standardize it or remove it?
 

Comment 1 by jsb...@chromium.org, Feb 15 2017

Usage graph:

https://www.chromestatus.com/metrics/feature/timeline/popularity/212

Looks like about 0.003%; has been declining but probably plateauing.

Next steps would be httparchive search to see how it's being used in the wild (i.e. does code fall back to lastModified), then propose a deprecation plan (e.g. deprecation message, wait a couple milestones, remove)
Cc: mek@chromium.org
mek@chromium.org - did this property get renamed to lastModified at some point? I still see references to that in the GitHub repository for the spec.
Cc: bsittler@chromium.org

Comment 4 by mek@chromium.org, Feb 15 2017

Yeah, seems like the 2012 spec used lastModifiedDate as the name of the attribute, while the latest spec renamed that to lastModified. Don't think standardizing both makes sense, so we should really just try to deprecate and remove the non-standard version.

Comment 5 by jsb...@chromium.org, Feb 15 2017

We have both - `lastModifiedDate` is a Date (now nonstandard), `lastModified` is a long long (in the standard)

Using the Date type fell out of vogue on the web platform.

Status: Available (was: Untriaged)
Summary: Remove non-standard (obsolete) API File#lastModifiedDate in favor of current File@lastModified (was: Standardize or remove non-standard API File#lastModifiedDate)
Summary: Remove non-standard (obsolete) API File#lastModifiedDate in favor of current File#lastModified (was: Remove non-standard (obsolete) API File#lastModifiedDate in favor of current File@lastModified)
Firefox supports File.lastModifiedDate, but issues a deprecation warning on the console. Safari does not have it. Haven't checked IE/Edge yet.
Cc: foolip@chromium.org
Labels: Hotlist-Interop
 Issue 839372  has been merged into this issue.
Cc: -bsittler@chromium.org annevank...@gmail.com
Per annevk in duplicate bug:

See https://github.com/w3c/web-platform-tests/pull/10821 for tests.

Seems it's just Chrome and Firefox that support this.
Hrm...  0.03% of page loads with more accurate metrics. That's disappointing. Hopefully a small number of big sites that can update...?
Components: Blink>Storage>FileAPI
Components: -Blink>FileAPI

Comment 16 by mek@chromium.org, Jun 18 2018

Cc: robertma@chromium.org jsb...@chromium.org pwnall@chromium.org
 Issue 839431  has been merged into this issue.

Comment 17 by mek@chromium.org, Jun 18 2018

0.03% is indeed on the high side, and with multiple browser supporting it, it seems even more likely to cause breakages...

But looking at the firefox bug, it seems they have removed it in the upcoming Firefox 61 release, so that gives hope. Should we wait and see what happens for them, or just try and go ahead with our own deprecation in M69 and removal in M70?
If I were an API_OWNER I'd say "wait and see" combined with a HTTPArchive search to see if we can identify the sites driving the number up.

Maybe add this to UKM metrics to help with "identify the sites driving the number up"?

Sign in to add a comment