Let webkitURL be an alias of the URL constructor

[foolip]

Measuring usage of attributes on the global object is hard because it's tainted by enumeration, but this is what we have:
https://www.chromestatus.com/metrics/feature/timeline/popularity/283

(Compare to https://www.chromestatus.com/metrics/feature/timeline/popularity/356 which is likely used very little but is also at ~0.1%.)

window.webkitURL has been deprecated in Blink for a long time, and I need to either remove it or get rid of the deprecation message. I'm leaning towards just spec'ing it, because Edge has window.webkitURL and it's trivial to support if you also have the infrastructure for other constructor aliases like WebKitAnimationEvent or, perhaps, HTMLDocument as an alias of Document (not yet implemented).

[annevk]

What would we add, NamedConstructor=webkitURL? @bakulf thoughts?

[domenic]

No, just the aliasing prose like HTML's

For historical reasons, Window objects must also have a writable, configurable, non-enumerable property named HTMLDocument whose value is the Document interface object.

We could consider formalizing this in IDL with some new extended attribute...

[annevk]

@miketaylr have you seen this in the wild as a problem for Firefox? Seems like we should just add it given that all other browsers ship with it.

@foolip how many aliases do we have? Is it worth adding IDL syntax?

[foolip]

Blink has a FooConstructor syntax for this, this one's attribute URLConstructor webkitURL.

Other aliases are WebKitTransitionEvent, WebKitAnimationEvent, WebKitMutationObserver, webkitIDBCursor, webkitIDBDatabase, webkitIDBFactory, webkitIDBIndex, webkitIDBKeyRange, webkitIDBObjectStore, webkitIDBRequest, webkitIDBTransaction, webkitIDBCursor, webkitIDBDatabase, webkitIDBFactory, webkitIDBIndex, webkitIDBKeyRange, webkitIDBObjectStore, webkitIDBRequest, webkitIDBTransaction, webkitMediaStream, webkitRTCPeerConnection, webkitSpeechGrammar, webkitSpeechGrammarList, webkitSpeechRecognition, webkitSpeechRecognitionError, webkitSpeechRecognitionEvent, webkitAudioContext, and webkitOfflineAudioContext.

For webkitURL specifically, it'd be worth looking into the risk that it's used to sniff WebKit, in which case it could make things worse for Gecko. It has been deprecated for a long time in Blink. I'd be very interested to hear if it's created trouble for Firefox.

(More generally I'd be interested to hear what non-standard stuff would be most useful to remove from Blink, there's a lot to choose from.)

[miketaylr]

@miketaylr have you seen this in the wild as a problem for Firefox? Seems like we should just add it given that all other browsers ship with it.

I'm not aware of any broken sites for Firefox due to webkitURL. Most usage I see is window.URL || window.webkitURL. But, that doesn't mean they're not out there. I'd really like to know what made Edge implement -- they've been really good at backing up these decisions with data. It's possible that having "Chrome" in their UA string has led them down code paths that require it.

(edit: after poking around a bit more on GitHub, there's quite a bit of code like https://github.com/catarak/beatsncode/blob/0bfe7025d4535a57930172c832e3fa0562f9b381/js/main.js. So even though I don't know about any broken sites, I don't doubt they're out there.)

[zcorpan]

A github search:
https://github.com/search?l=JavaScript&p=2&q=webkitURL+NOT+window.URL+NOT+self.URL+NOT+"typeof+URL"+NOT+hasOwnProperty%28%27URL%27%29&type=Code&utf8=✓

Chrome use counter is around 0.1%
https://www.chromestatus.com/metrics/feature/timeline/popularity/283

WebKit just fixed https://bugs.webkit.org/show_bug.cgi?id=172166 to stop exposing the webkitURL alias in workers.

We now have IDL syntax for this. It seems the shortest and least painful path to interop is to specify [LegacyWindowAlias=webkitURL].

[annevk]

Sounds reasonable. Is there a Gecko issue on adding IDL support for that extended attribute? Does IDL harness support it so I don't need to write more tests than just adding it to url/interfaces.any.js?

[zcorpan]

IDL harness support was added in web-platform-tests/wpt#5966

I can file a bug for Gecko for implementing LegacyWindowAlias.
Edit: https://bugzilla.mozilla.org/show_bug.cgi?id=1366738

[foolip]

It's possible that having "Chrome" in their UA string has led them down code paths that require it.

It also seems plausible that the opposite could also happen. Supporting certain APIs that are used to detect WebKit could also increase the pressure to put "WebKit" (or "Chrome") in the UA string.

[zcorpan]

Searching GitHub for "isWebKit webkitURL" reveals some instances of using this to detect WebKit... Not conclusive from this if it's better for everyone to drop it, for everyone to support it, or if we're locked to the current split...

https://github.com/tcha-tcho/famous_basic/blob/bbc619647dae4cc15e3f6bc3a531019f2fdfcde0/js/famous/famous-utils/Utils.js#L278
https://github.com/stephenykk/test/blob/9081e0086b23adfb02623e8816d5036200554fdf/work/tms/views/mod/browserlimit.jade#L2
https://github.com/linkedin/talkin/blob/d2682d684402e24641860405d8dbb504c6866935/src/talkin-template.js#L48
https://github.com/SkaarFace/all-tex/blob/838d8d8ac6745915cbd1dfb1121eb94914b53cc9/js/js-webshim/dev/shims/form-core.js#L4

[bakulf]

I'm OK with having [LegacyWindowAlias]. Temporary solution can be the use of NamedConstructor in gecko code.

[zcorpan]

OK great, then we can go ahead and merge.