311482 - After setting security.checkloaduri to false, file URLs are still forbidden

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[s.marshall]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

In Firefox 1.5 beta 2, I am trying to make pages with links to file URLs, such
as the following:

<script src="file:///c:/hack.js" type="text/javascript"></script>

This is prevented by a security error which appears in the Javascript console:

Security Error: Content at
http://lyceum.open.ac.uk/temp/firefoxbugs/filelinks.html may not load or link to
file:///c:/hack.js.

This behaviour is as designed. But, available documentation suggests that if you
set the property security.checkloaduri to false, this check should be bypassed
(thus allowing developers etc. to make their own browsers work). In fact,
setting that property to false in about:config makes no difference and the error
still appears.







Reproducible: Always

Steps to Reproduce:
1. In about:config, set security.checkloaduri to false
2. Open Javascript console and clear it
3. Visit http://lyceum.open.ac.uk/temp/firefoxbugs/filelinks.html

Actual Results:  
Security errors appear in the javascript console.

Expected Results:  
After turning off security.checkloaduri there should be no security errors. If
you have the file c:\hack.js, it should run.

Maybe this is a documentation issue and there's some other preference that needs
setting? security.checkloaduri is the only one I found when googling for that
message.

Comment 1

[Ria Klaassen (not reading all bugmail)]

See Bug 310386.

Comment 2

[Elmar Ludwig]

This pref does no longer exist in newer Firefox releases, see:

http://kb.mozillazine.org/Links_to_local_pages_don%27t_work

Comment 3

[:Gavin Sharp [email: [e-mail]]]

*** Bug 312684 has been marked as a duplicate of this bug. ***

Comment 4

[Elmar Ludwig]

*** Bug 331348 has been marked as a duplicate of this bug. ***