@PaoloBiagini I didn’t get a chance to test it, yet (I will do so later today and then write again). However, the main thing is that this wouldn’t give you any messages, but just do nothing when the button/link gets clicked…
I’ve just tested it on Windows: unfortunately, clicking the button nothing happens; even no message in the console.
any progress ? on this work around on windows
Nothing new, as far as I know
I confirmed it doesn’t work on Windows at this point in time.
I have also confirmed the redirect option I suggested above appears to have been a bug that’s been fixed or required the Apple plugin to handle the redirects or have a registered handler to work.
In Windows the file protocol does not open a web page the same as it did on Mac. So I setup a web page at http://mydomain to redirect to file://localhtmlfile. I tested redirecting and file://location_a would redirect to file://location_b.
http protocol worked on Windows I sent the url in the hyperlink to http://mydomain/launcher.html?url=encryptedfilepathhere.
When launcher.html page was loaded I parsed the url parameter and set the windows.location.href to the unecrypted file path. Nothing happened. I tried manually setting the href in the console. Same thing no change.
I guess you can’t redirect from a
http to a
file location. You may be able to redirect to another registered protocol and launch applications that way. I haven’t tried.
So then, using the same launcher.html page, I added a hyperlink on the page and set the url that the users could click. Surely you should be able to go to a local page (file://) by manually clicking on a link? That didn’t do anything either.
Since that didn’t work I copied the unecrypted file path into a text input and added a copy to clipboard button right next to it. This allows the user to manually copy the url and then paste it into the browser address bar.
As I was adding copy to clipboard functionality to the web page I remembered that I already had this ability in the plugin.
The only advantage in the end is that by setting up an http launcher page the user could open their browser and make it the active window and then paste the url in the browser.
Since opening file or folder or launching a registered protocol works on Mac but not on Windows (or the browser) I’m guessing it’s a Windows safety mechanism (or limitation of the underlying API).
But in the browser not redirecting to a local file from within a browser from an http address might be a security issue.
If it’s a security issue, there’s an argument here. One is that if you installed the software then that means you trust it otherwise why install it? But if it’s failing silently that’s making a decision for you. It should leave that up to you.
At the plugin level, the OS level and at the browser level, any of them could have opened up a dialog window and asked, “Do you want navigate to ‘file://…’?” A per privilege permission system, like in the browsers, at any of those domains would fix this.
@kerrishotts Is the limitation in Windows with the underlying API being used or is it a difference in security mechanisms between OSX and Windows?
May be we can try deeplinking protocol and make simple application to open suck links does any one tried this i mean how plugin deeplinks works in new api
I think UWP has more sandboxing when it comes to triggering URI schemes. I think a few will work (try
mailto, for example), but I’m not sure arbitrary
file:// access is an option. Any ability to launch external apps using
a tags is pretty much luck at the moment.
Not that we’re not thinking about ways to handle this, but it’s not a simple solution. Even rendering a popup dialog means that we have to consider localization, user experience (does it pop up every time? once? etc.), and more. So we want to make sure we get this right without incurring unnecessary security and privacy risks for XD users.