Apr 10 2019 04:25 AM
Apr 10 2019 04:25 AM
file: links seems to be ignored in this version of Edge (like they are in Chrome). In the previous version of Edge however (and all IE versions), clicking on a file: link opens the original document.
This is why by the way we are still using IE / Edge at my office. A lot of important intranet applications allow users to upload document and modify them later. Using Chrome, the document has to be downloaded locally before editing, and then re-uploaded after editing. With IE/Edge, the original document opens in Word/Excel/Acrobat in edit mode. The user just have to press CTRL+S to save it.
I really hope Edge will keep this behavior.
Apr 10 2019 04:30 AM
Apr 10 2019 03:18 PM
@Kneecht"Use SharePoint or similar products," sounds to me like "spend many $100,000s of dollars on licensing, hardware and administration/support payroll per year in perpetuity" to maybe solve a problem that was previously not a problem, and cost $0.
File:\\\ links are plenty good practice when they're used responsibly in a secure, local intranet / web app environment. I need to link to Windows folder paths and files in non-SharePoint apps, period.
IE 11 or the EdgeHTML version of Edge should hopefully stick around for legacy support if Edge Chromium can't support file:\\\ links due to inherent Chromium limitations, but it would be fantastic if MS's future flagship browser supported them along with all the latest bells and whistles.
Aug 20 2019 01:21 PM
Just adding that we are also heavy users of the File:// links on our intranet.
Not having this feature would limit our switch from the old Edge browser.
Aug 20 2019 02:00 PM - edited Aug 20 2019 02:06 PM
@mach1-69 Same here. We use SharePoint 2013 as a project manager - it has many task type lists. They control workflow for massive amounts of documents and photos that live on our network shares. The actual documents are managed by other applications and syncing SharePoint libraries isn't feasible for the number of documents and the number of people.
One of the only reasons we really stick to IE11 is support for file:// We also drive complex .bat files that securely log and open Excel spreadsheets from our network share. Also why we will be sticking with SharePoint 2013 since SPO doesn't play nice with file:// in their hyperlink list columns.
So far the Dev Edge is honoring file:// in IE Mode so that's promising.
Oct 08 2019 03:00 AM
This is also the most important feature for our company's intranet ! In the past, we used IE as our main browser. Now, we use Firefox with an extension, but we still have some issue when the file link is inside an iframe. In the futur, we plan to use the new Edge browser if the file link are supported.
Many users see a security problem with file link, but this can easily mitigate with options like "open only non-applicative files" or "open only files from theses secures servers : ___", etc.
Feb 11 2020 02:27 AM
Nothing new about this?
A GPO would be nice, where file links could be alowed for defindes file Servers.
Like Firefox has it:
Mar 03 2020 07:11 AM
You can do this straight from the about:config dialogue. Open the following page: about:config of Firefox. I am not 100% sure if it works without a restart using this method.
Right click - New - String.
Name: "capability.policy.policynames" value: "localfilelinks"
Name: "capability.policy.localfilelinks.checkloaduri.enabled" value: "allAccess"
Name: "capability.policy.localfilelinks.sites" value: "http://site1 http://site2:8080 https://site3"
Note that the sites are a space-separated list. Include protocol. Include port numbers if they are not the default.
And I support an application where linking to files on network drives is still used. Which is why it was convenient that IE supported it. And worthwhile to get Firefox to work as well.
Mar 12 2020 05:53 AM
We've just started the first round of internal testing and this was one of the first issues pointed out.
We have a lot of file:// links to our central fileserver on our intranet website and not having them work at all is a big problem.
I've worked around the issue for now by adding our intranet server to the Enterprise Sitelist and having Edge render the website in IE Mode. That way the file:// links are working again. But this should definitely not "become a thing".
A whitelist of sorts would be nice. File:// links to any server/location listed on that whitelist would work, while all other file:// links would behave like usual - not do anything. That would be nice. It would allow us to whitelist our central fileserver while keeping "security high".
I've also opened a case about this, lets see if it leads somewhere.
Apr 01 2020 11:44 PM
@JeffOwens I just got an update yesterday. They are goig to raise awareness about this issue with the product team soon-ish. Whether or not they will implement anything in regards to this issue is unclear at this point though.
For now the suggestion seems to be to either change all your links, use IE or configure Edge so that it uses IEMode for the entire website you have your file:// links on.
Apr 16 2020 04:59 AM
For anyone else interested, we changed all our file:// link references to localfile:// and implemented a new protocol handler in the registry.
Since this issue only applies to our intranet web application that we've developed internally, it was an easy thing to deploy (you might be able to do it via group policy if you're running AD or via an easy EXE to make those if not).
Also, since this is a registry edit, the protocol will be recognized on any browser.
That's our work-around for now.
Apr 20 2020 12:36 PM
@JeffOwens +1 ! This is what we have done finally. We just had to implement a new URI Scheme handler to mimic what we had in IE11. It works with all modern browsers.
If anybody want directions, please tell me. (Note: I'm the guy who posted the initial subject - I'm working for another company now).
Best regards JeffOwens.
Apr 20 2020 01:15 PM
But I told them that I'd like them to at least implement something that tells the user why/that file:// links aren't working. Currently Edge simply does nothing when you click a file:// link. They seemed kind of receptive to my idea to at least show an error/warning MsgBox or something along those lines when a user clicks on such a link. No idea when they are going to add that though .. if they are.