How the new Edge will handle file:// URI ?

[sylvainrodrigue]

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.

[#2]

@JeffOwens Hi, can you send me more information about your solution, please.

[#3]

@narutards- You have mentioned that you have logged a case for this issue. Have you received any response from Microsoft? If yes, could you please share?

[#4]

Could you please share how you implemented the URI Scheme handler?

[#5]

@SoumyaRaju - See the full resolution of the case below:

Cause:
The deprecation of file:// protocol links in Edge is by design. It has been inherited from the Chromium project and it is an expected behaviour that file protocol links are not open in Edge, for security reasons. There are other implementations that also allow the sharing and access of files without resorting to the File protocol, which has security risks associated with it: https://textslashplain.com/2019/10/09/navigating-to-file-urls/.

The lack of a warning or error message from Edge to the user when such a navigation is blocked has been acknowledged as a bad user experience which can lead to confusion and misunderstanding of this as an expected behaviour. As such, it has been flagged a bug that should be fixed in the future.

Resolution:
The short-term solution is to render the affected page in IEMode, where the issue does not occur. The longer term solution is to replace the URLs on the page or fully replace the page with Sharepoint, given that it is particularly geared towards this type of implementation.

[#6]

@sylvainrodrigue - Could you please your solution?

[#7]

@SoumyaRaju Here's what I did...

addLocalMyFile.reg:

     Windows Registry Editor Version 5.00

     [HKEY_CLASSES_ROOT\Myfile]
     @="URL:My Local File Protocol"
     "URL Protocol"=""

     [HKEY_CLASSES_ROOT\Myfile\shell]

     [HKEY_CLASSES_ROOT\Myfile\shell\open]

     [HKEY_CLASSES_ROOT\Myfile\shell\open\command]
     @="powershell.exe -Command \"$val='%1'; $val = $val.Substring(10, $val.length - 10).TrimEnd('/').Replace('/','\\'); & 'EXPLORER.EXE' $val\""

Apply the above registry change to each client machine.  Then, instead of...

     lb.Attributes.Add("onclick", "javascript:window.location.href= 'file:///" & fileToOpen2 & "'; return false;")

Do this...

     lb.Attributes.Add("onclick", "javascript:window.location.href= 'Myfile://" & fileToOpen & "'; return false;")

[#8]

@MartyMiller 

Please allow me to make sure I understand?

1. You created a new registry key named "localMyfile" directly under HKCR

2. Then, created a child key named "shell" and

3. under "shell" created an key named "open" and

4. within "Open" created another key named "command"

5. in the "command" key, you entered the string:   @="powershell.exe -Command \"$val='%1'; $val = $val.Substring(10, $val.length - 10).TrimEnd('/').Replace('/','\\'); & 'EXPLORER.EXE' $val\""

I will feel good if I am following so far, but I am lost at the next steps! Where did you do this?

"lb.Attributes.Add("onclick", "javascript:window.location.href= 'file:///" & fileToOpen2 & "'; return false;")

Do this...

lb.Attributes.Add("onclick", "javascript:window.location.href= 'Myfile://" & fileToOpen & "'; return false;")"

Please forgive me if I seem a little ignorant? It is because I am....

Dan Beuscher. 

[#9]

addLocalMyFile.reg is the registry file name I used to apply the corresponding registry changes. The javascript code is just example code. The idea is wherever you used file:// in your intranet website to open files from their current location, use Myfile:// instead. This will force your browser to trigger powershell to launch the file using the default app associated with the file extention you are opening.

[#10]

Note that creating a URL Protocol handler means that any site on the internet can attempt to open it, and that Windows Explorer can be coaxed into running any executable on your system, making this a rather risky workaround.

[#11]

Thanks for the warning. We will likely change the protocol to only open certain document types to limit its ability.

[#12]

If IE is deleted, or at least disabled in "add and removed windows components", and the only Windows browser available to users is Edge; does this warning still apply?

[#13]

I think the answer is yes. A bad guy could send you an email or direct you to a website that has a hyperlink that uses your custom URL protocol and launch whatever you're custom protocol allows to be launched on your in internal client machines. For example:
<a href="Myfile://C:/Windows/system32/notepad.exe">notepad.exe</a>
will launch Notepad.exe on the client machine using the registry setup I mentioned March 3rd. The powershell command in the registry needs to be changed to only allow .DOC files to be opened if that is all you need.

[#14]

Thanks for the input.
I am working toward getting my intranet off of IE altogether, possibly rebuilding it in Joomla. I am hoping I can make it all work this way, and keep my intranet completely behind my firewall.

[#15]

Instead of notepad.exe, the bad guys could launch something that would allow them to tunnel through your firewall, or just misbehave in general. That is the risk that needs to be mitigated.

[#16]

It is not a risk if it is well implemented, like on Firefox with many configuration options. By default, the feature is disabled and you have to activate it for a domain and you can allow or exclude to open some types of files. For my office, we have moved to Firefox and our intranet works awesome.
Microsoft should think about that question as they would like Edge to be THE browser for businesses with cool features in work environment...

[#17]

new Edge Browser and file:// Links.

Maybe waiting, will resolve this problem.
I've some news from Microsoft during a ticket.
Microsoft is working on this issue.

Last news I have got from the product group is that this scenario is committed for the current quarter.
They will be able to confirm dates closer to mid-Feb.

The last update we got is:
>Regarding timelines, we're hopeful to have something figured out this quarter,
which would likely become available in Edge 90/Edge 91 release
( Microsoft Edge release schedule | Microsoft Docs<https://docs.microsoft.com/en-us/DeployEdge/microsoft-edge-release-schedule>).

[#18]

do I understand correctly that perhaps in the upcoming releases they will add the ability to enable support for the protocol file:// ?

[#19]

You can use EdgeView2 control in which you can map local directory to virtual one using SetVirtualHostNameToFolderMapping function.

webView2.CoreWebView2.SetVirtualHostNameToFolderMapping("my.virtual", "@"C:\MyVirtual\",
                    CoreWebView2HostResourceAccessKind.Allow);

After that you can use this syntax to access your file

"https://my.virtual/" + "myFile.txt"

[#20]

@Michel LAPLANE can you elaborate or explain like I'm 5? Thanks!

[#21]

It's really unfortunate that Chrome or Edge does not offer an ADMX to implement this as Firefox has this added now and it works great for local files with no stupid registry entries or adding extra code to internal websites or using IE Mode.

https://support.mozilla.org/en-US/questions/1264779

Come on Chrome and Edge it's 2021 get it added :D