Since 39.0, local links don't work.
Local links in Firefox do not work since 39.0 came out. I can copy and paste the link in the top of the browser and it will work, but clicking on the link will not do anything at all. The path is correct. I am using the format "file://///path/to/file.jpg" Please help.
Toutes les réponses (17)
The correct format to open a local file is file:///C:/path/randomimage.jpg. You added one more slashes(Only three required ///).Moreover verify you have the file exactly in the path which you type.
premm krishna shenoy said
The correct format to open a local file is file:///C:/path/randomimage.jpg. You added one more slashes(Only three required ///).Moreover verify you have the file exactly in the path which you type.
The file path is 100% correct and was working before 39.0. If I change to three /// from the five, the path no longer works at all.
These are many different files and paths spread over many servers or mapped drives. Like I said, all was fine before 39.0
What was the last version in which local links worked for you?
If you check the browser console (Ctrl+Shift+j), are you getting one or both of these error messages:
(UNC path)
Security Error: Content at http://serverA/dir/page.html may not load or link to file://///serverB/dir/page.html.
(mapped drive)
Security Error: Content at http://serverA/dir/page.html may not load or link to file:///M:/dir/page.html.
If it's not an exact match, where do you see differences in the errors you're getting?
For a very long time, users who wanted to use links to file paths from http/https pages have needed to add custom preferences to either the prefs.js or user.js file, or use an extension to manage those custom settings. (E.g., http://kb.mozillazine.org/Links_to_local_pages_do_not_work)
Is it possible that the system with the problem has undergone a Firefox Refresh or Reset? The tell-tale sign is an Old Firefox Data folder on the desktop containing the old settings folder and the files with the necessary customizations, as well as any previously installed extensions. That would explain how Firefox lost the customization and now won't follow those links.
jscher2000 said
What was the last version in which local links worked for you?
If you check the browser console (Ctrl+Shift+j), are you getting one or both of these error messages:
(UNC path)
Security Error: Content at http://serverA/dir/page.html may not load or link to file://///serverB/dir/page.html.
(mapped drive)
Security Error: Content at http://serverA/dir/page.html may not load or link to file:///M:/dir/page.html.
If it's not an exact match, where do you see differences in the errors you're getting?
For a very long time, users who wanted to use links to file paths from http/https pages have needed to add custom preferences to either the prefs.js or user.js file, or use an extension to manage those custom settings. (E.g., http://kb.mozillazine.org/Links_to_local_pages_do_not_work)
Is it possible that the system with the problem has undergone a Firefox Refresh or Reset? The tell-tale sign is an Old Firefox Data folder on the desktop containing the old settings folder and the files with the necessary customizations, as well as any previously installed extensions. That would explain how Firefox lost the customization and now won't follow those links.
I'm getting the first error when I check the log. Firefox auto updated to 39.0; everything worked before it. The website is https and all the links are to a folder on a shared drive.
I hate to start editing any path as like I said they all worked a week ago before I upgraded to Firefox 39.0
Hi Rocknrolla26, can you confirm that there is no Old Firefox Data folder on the desktop with a recently modified semi-randomly-named folder inside? If it exists, we can use that to sort out what changed.
Otherwise, please check whether you have any rules in a prefs.js file or user.js file to override the standard security block on HTTP(S) pages accessing FILE URLs. To do, that:
Open your current Firefox settings (AKA Firefox profile) folder using 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
In the first table on the page, click the "Show Folder" button. This should launch a new window listing various files and folders in Windows Explorer.
Scroll down and look for prefs.js -- if you see a file named prefs (of type JScript) but not prefs.js, Windows may be hiding file extensions from you. To work with files as accurately as possible, I suggest unhiding them. This Microsoft support article has the steps: http://windows.microsoft.com/en-us/wi.../show-hide-file-name-extensions.
Right-click > Edit prefs.js and it should contain numerous custom(ized) preferences. The ones needed to allow file access look like this, but the "localfilelinks" part may be a different name:
user_pref("capability.policy.policynames", "localfilelinks"); user_pref("capability.policy.localfilelinks.sites", "https://intranetserver"); user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");
Can you find anything like that in prefs.js or in a user.js file, if you have one?
There is no folder/file on the desktop. The prefs.js file does not contain anything like the three lines you listed above. I has a lot of stuff in it, but nothing like those.
It goes right from 'browser' to 'datareporting'. Nothing about capability.
And there is no user.js file either?
In that case, you will need to add the rules by hand. The critical part is to updating the second line to match your server or servers that contain the links. In other words, the rule declares that HTTP(S) pages on those servers are allowed to link to FILE URLs anywhere, you do not need to specify the location of the FILE URLs.
If you need to list multiple servers, separate them by a space. For example:
user_pref("capability.policy.policynames", "localfilelinks"); user_pref("capability.policy.localfilelinks.sites", "https://server1 https://server2"); user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");
Before editing prefs.js, Firefox should be closed. I recommend using the Exit command, either:
- "3-bar" menu button > "power" button
- (menu bar) File > Exit
Please allow a few moments for Firefox to complete its file updates. Then you can right-click > Edit the prefs.js file and paste your three new lines at the end of the file and save the change.
When you start Firefox up again, it should ingest the rules and allow the access.
Any improvement?
there is no user file. So in editing the prefs.js file, do I only need to edit the second line? the first and third stay the same?
Those three lines are the example from the mozillaZine article. The only part you need to customize is/are the server names relevant to your organization.
I added the three lines. I edited the second line with the server path that the files are on. Still nothing...
When you say
I edited the second line with the server path that the files are on.
You have just the protocol and host name, correct, like:
https://server1
no trailing slash, directory, etc.
And you still get the same error in the console, or has it changed?
If that doesn't work, you could try the LocalLinks extension mentioned in the mozillaZine article. It adds a new option to the right-click context menu for links that you can use to bypass the standard security policy.
Yes, I have just the 'https://server1' and I am getting the same error as before in the log.
(Thank you for your help so far)
It's the same 'Security Error: page may not load or link to file'
I tested with a page I created on an internal web server and it worked, the only differences being (1) my server uses HTTP and not HTTPS, and (2) I created a user.js file for the three lines. At startup, Firefox merges the preferences from user.js into prefs.js, so that shouldn't make any difference, but I mention it just in case you want to try it that way.