Talk:Links to local pages do not work: Difference between revisions

From MozillaZine Knowledge Base
Jump to navigationJump to search
(I have a brand new install of 1.5.0.1, and the link do nothing)
Line 56: Line 56:


I have not upgraded from an old profile.  This is a fresh install of 1.5.0.1.  I desperately need this to work.
I have not upgraded from an old profile.  This is a fresh install of 1.5.0.1.  I desperately need this to work.
:You need to set the preferences as described in the article. --[[User:Unarmed|Unarmed]] 16:54, 8 March 2006 (UTC)

Revision as of 16:54, 8 March 2006

Maybe a good idea to rename/move this to Links to local pages do not work. The URL-encoded apostrophe makes links posted in forums look silly. Thoughts? Jonnyq

I would not be opposed to that. The reason a contraction was used in the first place was to mirror Image tooltips don't work. --Unarmed 15:15, 29 August 2005 (PDT)

I'm using Firefox 1.5 beta 1 but the solution provided here doesn't work for me. Does is work for anyone? --Agusmba 08:52, 26 September 2005 (PDT)

_______________________
I have gotten this to work for links to local files on my "C" drive...for example:
file:///C:/test.doc

...but I cannot get it to open files that are stored on a network drive. I have tried the following:
file:///H:/test.doc
file://///myservername/mysharename/test.doc
When I click on one of the links above, nothing happens. The formats are correct, however: if I right-click on the link, select "Copy link location", and paste it into a new tab, the file opens correctly.

All of this worked in Firefox 1.0.7 just fine.

So...it looks like the security policy capability in FF 1.5 isn't quite working correctly. --Steve66 08:25, 01 December 2005 (PDT)

I managed to get user_pref("capability.policy.default.checkloaduri.enabled", "allAccess"); to work, which I think is equivalent to the old way of doing it, which was user_pref("security.checkloaduri", false);
I couldn't get the policynames approach to work at all, not with local files nor with network shares. Steve66 can you describe exactly what you did to get it to work with local file names. I must be missing something.
BTW deletions are not managed gracefully. Once I had added user_pref("capability.policy.default.checkloaduri.enabled", "allAccess"); to user.js then I had to remove it both from user.js and from prefs.js to get it to go away. 80n 21:13, 1 December 2005 (UTC)
If you can get the default policy to work, you should be able to get the site-specific version working. Setting a default policy to ignore checkloaduri is a really bad idea when the alternative is available. --Unarmed 02:14, 2 December 2005 (UTC)
It is a bad idea but I don't have a better one - the alternative is broken - it doesn't work. 80n 08:43, 2 December 2005 (UTC)

New style doesn't work for me either... :(

With v1.5 (on windows), links like file://///server/directory/file.ext just don't work any more (they did in previous versions). I have the following lines in user.js:

user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites", "http://server");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");

But it has no effect. Contrary to this article, the security.checkloaduri setting is still there, but again has no effect.

I actually also need links formated like file:\\server\directory\file.ext to work, as my company intranet uses MediaWiki, which can only create links in this style.

This change really breaks my company intranet.. :( -Sprintstar 11:27, 7 December 2005 (UTC)

security.checloaduri is only "still there" if you upgraded from an old profile. Your syntax is correct, but I suggest closing the browser and looking in prefs.js to make sure the new preferences were applied there and, if they were, that there isn't any cruft from previous attempts in there. The other problem may be that you've put user.js in the wrong place; in that case, just use the ChromEdit extension to do your editing. --Unarmed 17:56, 7 December 2005 (UTC)
Thanks for your reply. You're right, I did upgrade from an old profile. My settings have been copied to prefs.js, and they're correct. I put user.js in the same place as prefs.js (C:\Documents and Settings\user\Application Data\Mozilla\Firefox\Profiles\t663obzx.default. I will uninstall Firefox completely and re-install it, that might help. -Sprintstar 08:39, 8 December 2005 (UTC)
I uninstalled Firefox, removed all the profile information, and re-installed it and now file://///server/directory/file.ext style links work, but file:\\server\directory\file.ext still don't work. Would it be possible to to allow links like this in future builds? -Sprintstar 09:23, 8 December 2005 (UTC)
Why not try setting $wgUrlProtocols to include file:\/\/\/\/\/ in MediaWiki?--Unarmed 00:13, 9 December 2005 (UTC)
Oh yeah, that allows me to use file://///server/directory/file.ext type links, which will do. Thank you.. :) -Sprintstar 10:43, 12 December 2005 (UTC)

I have a brand new install of 1.5.0.1, and the link do nothing

If I have a link file://///servername/share/test.doc, and click on the link, nothing happens, but like above, if I copy link location and paste in new window it does work.

I have not upgraded from an old profile. This is a fresh install of 1.5.0.1. I desperately need this to work.

You need to set the preferences as described in the article. --Unarmed 16:54, 8 March 2006 (UTC)