User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20060426 Firefox/220.127.116.11 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20060426 Firefox/22.214.171.124 File protocol handler doesn't seem to be passing MSWindows specific URLs to OS properly. When I receive the message with such URL in message body, clicking on the link does nothing. Copying the link to clipboard and exec'ing it thru (Win-R) "Run..." dialog works as expected and default application is launched. (IOW WinAPI's ShellOpen() comprehend such URIs). Reproducible: Always Steps to Reproduce: 0. echo "<h1>Hello</h>" > c:\hello.html # create "C:\hello.html" test file 1. Open mail compose window 2. Put into the message body text "file://C:\hello.html" 3. Save draft message & close compose window 4. Go to Drafts & open just composed message 5. Click on the file:// link Actual Results: Nothing happens. Expected Results: Default application is launched to open the file. This annoys me quite often, since in addition to corporate Intranet we have also number of public file servers. All desktops have same number of network drives attached so file:// links work okay across whole company. Instead of sending document it's just easier to send a file:// link to it. P.S. M$Outgluck works Okay.
file://C:\hello.html doesn't work, because of the backslash :( . It isn't allowed to act as a separator within the URI, due to the specifics of the URI specification. Microsoft products misinterpret these uris as a convenience to their users, but this is undefined behaviour. file://C:/hello.html is a valid, and windows will not have any trouble interpreting this uri as pointing to C:\hello.html. ---
Actually, I think my above comment is wrong, and it is not the reason (or at least the main reason) why the link wasn't working. Mozilla has a security feature where local files referenced by a file uri may not work. http://kb.mozillazine.org/Links_to_local_pages_don't_work
Adding the following lines to the prefs.js has no effect. No error, no message, nothing is logged in console. user_pref("capability.policy.policynames", "localfilelinks"); user_pref("capability.policy.localfilelinks.sites","mailbox://firstname.lastname@example.org"); user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess"); Where "xxx" is my user name on pop3 server, yyy.zzz.com - is pop3 server host name. (same as configured for my account). Or - since default mode is to save all incoming messages in local inbox - what kind of syntax shall I use for messages in local inbox? P.S. The added options, thou remain in prefs.js after relaunch, do not show up in about:config window ("Tools" > "Options" > "Advanced" > "General" > "Config Editor ...") Is that okay? Seems not Okay to me: I do not like idea of ghost options. P.P.S. Very minor appearance bug: the config editor isn't modal - three dots in the end of button name are not needed.
just try user_pref("capability.policy.localfilelinks.sites", "mailbox://"); this works for my pop mail, though, you may have figured that out already :D ... Add it to the user.js file (if you don't have one, create one). I tried using prefs.js but it didn't work for me either. (Mozilla would overwrite the prefs.js file, for some reason, no matter what ... ). I have no good idea if that is a bug or not, but using user.js, rather than prefs.js is a complete workaround imo. ---
(In reply to comment #4) > just try user_pref("capability.policy.localfilelinks.sites", "mailbox://"); > this works for my pop mail, though, you may have figured that out already :D > ... You ought to register for that kb.mozillazine wiki and add that information to the entry. I think this bug is basically a dupe of bug 135830.
Nobody disagreed, so duping. *** This bug has been marked as a duplicate of 135830 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.