User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 I use Lotus Notes at work and would like to use Mozilla as my default browser. Problem is, that file-links, that work with IE do not work with Mozilla = start a file-link URL from within Lotus Notes launches an application and opens up the requested file with the associated program (eg. OpenOffice Write), but not with Mozilla. If I cut & paste the same URL on URL-window, also Mozilla opens up the requested file. Also, when Mozilla has not launched the program, but has received the file-link URL in its URL-window, inserting the cursor in URL-window and pressing enter makes it continue and open up the target file. Reproducible: Always Steps to Reproduce: 1. 2. 3. Expected Results: Launched the program and opened the file as IE does.
Could you have the JS console open as you do this? Is a security exception thrown?
mitch: this sounds like a duplicate of the popular "file:// URLs don't load from web pages" bug.
Bug 122022 [ISSUE] file:// URLs in a http | https page do not work (clicking does nothing, do not auto-load, etc.) [dupe to bug 84128] Bug 84128 Need user-visible message when CheckLoadURI fails (eg, for links to file: urls)
*** This bug has been marked as a duplicate of 84128 ***
the question: file:// links are only loaded from the URL bar or from a file:// document. But this looks like Mozilla also blocks file:// links if you open mozilla with a file:// commandline-parameter (notus-lotes opens the default browser)
There were comments at various times that some combinations of valid-looking situations are still blocked. You can verify that w/ the js console, and you should file a separate bug if you have a test case. I think some people complained about handling of BASE tags, for example. I think you should put any bugs like that in the security component. Bug 122022 existst because so many of these problems appear here and belong elsewhere.
REOPEN: bz's question in #1 was never answered. until the reporter shows checkload.uri logged an error in the js console, I think we should leave this open. Perhaps it is not in the correct component? I don't know much about how extrnal URL requests are handled on launch.
-> benc (please send back if this is a unique bug or mark as a duplicate)
-> defaults. I'm not going to own a bug just because the problem description is incomplete. We tried to have a system where there was a default owner that was a placeholder for bugs w/o a clear problem description, but that isn't being used anymore.
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.