Currently, when a local file is opened in Google Chrome, the browser's address bar displays a file:// address that contains the path to the local file that is opened. In Chrome 70, Google has introduced a new "File" notification, as shown below, that is also used to indicate that a local file is open in the browser.
According to a Chrome Gerrit entry titled "Elide file scheme in omnibox", now that Chrome displays a File chip notification next to the address, there is no need to continue using the file:// URI scheme (Uniform Resource Identifier scheme) in the Chrome omnibox.
The Gerrit entry also includes a link to an image of what the Chrome address bar will look like without the file:// URI scheme. I used that mockup to show you the progression between Chrome 69, the currently Nightly build of Chrome 70, and how Google ultimately wants to display the addresses for local files in Chrome.
In the current Chrome 69 (69.0.3497.100 ) version, when user opens a file on their computer using Chrome, it will display an URL in the address bar that starts with file:// and then the path of the file is appended as shown below.
In the current Canary build of Chrome 70 (71.0.3555.0), a new File chip notification has been added to the omnibox as shown below. Note that the address bar still contains a file:// URI scheme in this version of Chrome.
Based on the Gerrit post, ultimately the Chrome omnibox will no longer show the file:// URI scheme and only show the "File" chip. This could look look similar to the following mockup that we created below.
If a users clicks on the File notification, according to this bug report, Chrome will display a message that tells the user "You're viewing a local or shared file".
While code posted to the Chrome Gerrit does not always make it into release, there is a good chance that this change will happen. This is because Google is making a concerted effort to remove what they feel is duplicate or unnecessary information from Chrome's address bar/omnibox.
For example, Google has already removed the https:// and http:// URI schemes and are instead displaying either a "Not Secure" notification for http sites and a lock for secure sites. We have also recently seen Google elide the WWW and M subdomains, but ultimately decide after a large outcry to allow the M subdomain to stay.
Bleeping Computer has contacted Google for comment regarding this change and other possible future changes, but had not heard back at the time of this publication.
Comments
hunkydoris - 5 years ago
Hi, I have a question about this - maybe you could help. I'm using Chrome for work and I need to open a lot of pdfs in Chrome and then I copy a part of the name of the file that I need to paste somewhere else. As of late, this has become annoying, I will try to explain: let's say the url for the dowloaded file is: C:/Users/User/xx-number-something. I used to double-click on 'number' to select it and then copy, but now when I double-click the edit mode is activated, and then the url changes to file:///C:/Users/User/xx-number-something which means the whole text is moved to the right, for which reason sometimes I click wrong and I can't quickly select the part I want. I tried to experiment with the flags by disabling the 3 Omnibox UI Hide Steady-State URL options I found (Scheme; Trivial Subdomains; Path, Query, and Ref) - in the explanation it says "Hidden portions are restored during editing" which I guess is what's happening, so I thought disabling the 'hide' would show the full path from the moment the file was downloaded and opened, so it wouldn't change on edit, but it doesn't seem to work. I also disabled Use all upcoming UI features. Is there any way to revert this back to the way it was or should I wait until they remove the 'file:///'; part althogether.