Devtools: [WIP] Implement enhanced devtools extension language APIs

Source/devtools/front_end/resources/ResourcesPanel.js

Index: Source/devtools/front_end/resources/ResourcesPanel.js
diff --git a/Source/devtools/front_end/resources/ResourcesPanel.js b/Source/devtools/front_end/resources/ResourcesPanel.js
index af0b6c210c6e8b6d2215251fd0c54a0be9d069e8..dff59a7bba98765c55d0039efe43ceb4de063891 100644
--- a/Source/devtools/front_end/resources/ResourcesPanel.js
+++ b/Source/devtools/front_end/resources/ResourcesPanel.js
@@ -2335,7 +2335,7 @@ WebInspector.FileSystemTreeElement.prototype = {
 
     get itemURL()
     {
-        return "filesystem://" + this._fileSystem.name;
+        return "filesystem:" + this._fileSystem.name;

[pfeldman, 2015/08/13 21:15:46]

This is only used to restore last used item.

[wes, 2015/08/14 00:55:05]

This may be pedantic, but it's the result of going through (literally grep) and
unifying every 
single url returning function which dealt with files (file:// or filesystem: or
filesystem://) 
to all uniformly return `filesystem:` URLs rather than the menagerie of URL
prefixes each API 
returned before. The lack of consistency made things very confusing. Though this
one wasn't directly
used, it still got caught up in the mass change. One of my other comments asks
which should be
considered the 'canonical' URL for a file.

[pfeldman, 2015/08/17 21:15:51]

Right, except for these are used for different purposes and are different on
purpose.

[wes, 2015/08/25 18:13:18]

Okay - but why is there also both filesystem: and filesystem:// URLS? (And the
filesystem: URLs used for workspace files aren't even parsed as valid URLs by
the URL class, BTW, since it lacks the // to delimit the protocol).

     },
 
     /**