Using buildid 2002040210 on Windows XP Reproducible: Always Steps to Reproduce 1. Get someone using N.4x to email you a link to a file on a shared network drive. 2. Try clicking on link Actual Result. Clicking on link does nothing Expected Result: Clicking on link opens file from shared network drive.
This works fine in NS4.x so I'll mark as 4xp
Invalid. Remote content cannot link to local content for security reasons. Mail is remote content. See bug 84128 for discussion on the issue as well as the pref you can set to disable this security check (in bug 84128, comment 20)
Bug 84128 is to do with browser file:// links and whether it pops up a window and what sort of window it should pop up. This is a change in behaviour from NS4.x and users, used to NS4.x, will be confused by the change and lack of explanation. Corporates tend to encourage use of links to files on shared network drives rather than sending huge attachments round and eating up disk space. A file:// link in an email doesn't pop up any sort of window error or dialog! The user_pref("security.checkloaduri", false) mentioned seems to be to black and white, there should be some sort of grading. I think the Mozilla should be able to determine whether it is an internal e-mail (or a list of safe domains which it auto-fills with your domain when you run mail account wizard) or an external e-mail (or those not in your list of safe domains) and have preferences to let you configure what Mozilla does with file links in each circumstance. Reopening and tweaking summary.
Splitting no information pop-up part of bug into bug 157885. I'll alter this bug to be an enhancement request.
Adjusting summary original summary was "file:// links sent from NS4.x do not open in Mozilla or pop up an explaination"
Raising security to normal, the user should be able to click on a valid file url link. Also set component to Security:General
*** Bug 179511 has been marked as a duplicate of this bug. ***
Any status on this bug?
*** Bug 225425 has been marked as a duplicate of this bug. ***
Bug 233108 covers the more general case and has a patch. *** This bug has been marked as a duplicate of 233108 ***
This is different, imo... That bug's patch will let you give your mail messages access to all files on your hard drive. Doing so, imo, is stupid. We need a better setup for mail messages.
*** Bug 266261 has been marked as a duplicate of this bug. ***
*** Bug 301173 has been marked as a duplicate of this bug. ***
*** Bug 337581 has been marked as a duplicate of this bug. ***
The first part of a fix to this bug is probably implementing a way of checking if the file resides on a networked drive. AFAIK in non-windows environments this will be any link starting with file://///, in windows there is that but also networked drives which we should be able to determine using a call to GetDriveType