This is admittedly a bit off-topic for sitepoint, but I can’t find any help with it elsewhere, so I’m casting a wider net.
I run a couple of applications that crank out web pages, and I always want to preview them locally before uploading. Suddenly, in Firefox 50 on Win10, it refuses to open a URL like file:///C:/Users/JT/Documents/MrN/Site/index.html. The message is:
Access to the file was denied - The file at /C:/Users/JT/Documents/MrN/Site/index.html is not readable. - It may have been removed, moved, or file permissions may be preventing access.
No problem with Chrome or Edge (which tells me that this isn’t some sort of Windows permission problem), and no problem with any browser, even Firefox, on macOS.
I’m guessing this is a “security thing,” but I’ll take the risk. Having to upload every page, then check it, would be a pain. For the moment, it’s driven me back to Chrome as my default, though I really prefer Firefox.
Anyone know how to defeat this? Everything I’ve seen online elsewhere refers to config settings in Firefox that no longer exist.
Tried that, but it doesn’t work in FF50. And remember, this isn’t a case in which I’m accessing an http:// URL that contains a link to a local file, which is what that solution seems to address. I am, in effect, just double-clicking an index.html file in Windows File Explorer.
Setting up a localhost server isn’t really an option. For example, I’m editing index.html in Notetab Light (favorite editor). To preview the page, I hit CTRL-T, which opens the file in my default browser. I can’t modify the protocol - it’s file://something. Ditto for the web page-generating application I’m using - the “Preview” button feeds file://something to the browser, and I can’t change that.
I’ll tinker with a localhost server - maybe if the file I’m editing is on that server, the editor will use the correct protocol to open it. I don’t hold out much hope for that, however. For the moment, defaulting to Chrome is a lot simpler!
An interesting approach, and while it’s a little clunky, it’s workable. If Chrome joins the “fun” and similarly blocks local files, that may be the way to go, though with my web-page generating app, that’s not an option. I’d have to do an upload (to a hidden directory) after every “make the pages” operation, refresh the browser, then move the new version to the production directory on the server if the results were OK. That’s a lot of faffing about.
Ironic that Edge hasn’t implemented these kinds of restrictions - after all, it was always IE that put you through all sorts of hoops to get around its pathological need to protect you from the supposed monsters under the bed.
A new symptom to report. I did a clean reinstall of Firefox - even deleted the existing profiles. No import of data from any other browser. No extensions. No sync with Firefox on my macOS laptop (this is a Win10 desktop machine). Hey presto, local files could be opened once again!
Close Firefox, launch it again, and the problem is back:
Access to the file was denied - The file at /C:/Users/JT/Documents/Site/index.html is not readable. - It may have been removed, moved, or file permissions may be preventing access.
(BTW, “Run as administrator” makes no difference - I thought that might be the key.)
Solution found, thanks to jscher2000 over on the Mozilla Support Forums. In case anyone else encounters this, here’s the skinny:
One of the headline changes in Firefox 48+ is e10s, which separates the browser interface process from the page content process (content processes move into plugin-container.exe). When you first install Firefox (or flush your profile), Firefox assesses whether your system is compatible with e10s and sets a flag to enable it in your next session. That could explain how the second run was different from the first…
Are you using e10s?
You can check whether you have this feature turned on as follows. Either:
“3-bar” menu button > “?” button > Troubleshooting Information
(menu bar) Help > Troubleshooting Information
type or paste about:support in the address bar and press Enter/Return
In the first table on the page, check the row for “Multiprocess Windows” and see whether the number on the left side of the fraction is greater than zero. If so, you are using e10s.
If you are using e10s:
To help evaluate whether that feature is causing this problem, you could turn it off as follows:
(1) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button promising to be careful.
(2) In the search box above the list, type or paste autos and pause while the list is filtered
(3) Double-click the browser.tabs.remote.autostart.2 preference to switch the value from true to false
Note: the exact name of the preference may vary, but it will start with browser.tabs.remote.autostart
It gets weirder, however. The failure occurs only when accessing a local file in the Windows Documents or Pictures library - no problem from any other location on the machine. So at some deep level, there’s some kind of collision occurring between Firefox and the Windows permissions or links. Tough to sort out. I’ll post back if I find out anything further.
Sure enough, when I went in and explicitly gave the Owner of Documents and Pictures all file permissions, the failure disappeared, even with e10s enabled. The Gnomes of Redmond® strike again!