SRC parameter not working in Mozilla when path is included

[wylbur37]

(This is a re-post of something that apparently did not post correctly
the first time, so if there's more than one copy, please ignore the
duplicate).

I normally use Mozilla 1.4 on Windows XP Pro.
As I was developing some test webpages, I discovered that the SRC
parameter doesn't seem to work when a path is used with the filename.

In one example, when I want to run a JavaScript from an external file
(i.e., not inline), I would do the following ...

<SCRIPT LANGUAGE="JavaS cript" SRC="program.js "> </SCRIPT>

If "program.js " were in a different subdirectory than the .htm file
referring to it, the filename would have to be prefixed by the
pathname as follows ...

<SCRIPT LANGUAGE="JavaS cript" SRC="/mydir/program.js"> </SCRIPT>

But when I ran the above from within an .htm file loaded locally into
Mozilla, it did not work. (The result was as if the above code weren't
there). However, when I ran the identical code on Internet Explorer
(v.6), it worked.
In another, even simpler example, the code to put an image on a
webpage is ...

<img src="picture.jp g">

Again, if "picture.jp g were in a different subdirectory than the .htm
file referring to it, the filename would have to be prefixed by the
pathname as follows ...

<img src="/mydir/picture.jpg">

When I ran the above from within an .htm file loaded locally into
Mozilla, it did not work. (The result was as if the above code weren't
there). However, when I ran the identical code on Internet Explorer
(v.6), it worked.
By the way, I tried using backslashes instead of forward slashes. In
both cases, it still worked on Internet Explorer but not on Mozilla.
The SRC parameter seems like a fairly frequently used parameter for
the developers of Mozilla to overlook it. Is this really a bug in
Mozilla or is it just some option/switch in Mozilla that I didn't set
properly?
_______________ _______________ ____
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003

[Lee]

wylbur37 said:

The SRC parameter seems like a fairly frequently used parameter for
the developers of Mozilla to overlook it. Is this really a bug in
Mozilla or is it just some option/switch in Mozilla that I didn't set
properly?

Neither.

An URL beginning with a "/" is invalid. Since it isn't relative to
the URL of the current page, you must specify the protocol. IE lets
you get away with it, assuming that you mean the "file:" protocol.

There are many reasons why it's bad for a browser to make that sort
of assumption, but they are balanced by the fact that accepting bad
code will trick some people into thinking that the other browsers
are buggy, and so they will be less likely to support them, giving
the more lenient browsers a market advantage.

The correct tag would be:

<script type="text/javascript" src="file:///C:/mydir/program.js">

You should see that format in the Location bar when you open any
local HTML file.

[Lasse Reichstein Nielsen]

Lee <RE************ **@cox.net> writes:

An URL beginning with a "/" is invalid. Since it isn't relative to
the URL of the current page, you must specify the protocol. IE lets
you get away with it, assuming that you mean the "file:" protocol.
It is not invalid in general. As an URI fragment, it defines an
absolute path, relative to the current protocol and server. It is
correct for IE to assume the "file" protocol and "localhost"
server. Where it gets dicey is what happens on local files.

If the URL to the local file is
file://localhost/c:/somedire/myhtml/foo.html
then using the URI fragment in that context "/mydir/program.js" should
give
file://localhost/mydir/program.js
That is most likely not what is wanted. For one thing, it doesn't include
a drive letter. I guess it is what Mozilla does (ok, let me check ... yes,
it gives
file:///mydir/program.js
which is equivalent - omitting the server name in a file protocol means
the server is localhost).

If you compare it to IE, the same test gives:
file:///D:/mydir/program.js
(my test file was on the D: drive). That is incorrect according to
the definition of URIs, but obviously works better on windows based
machines.

Mozilla also runs on, e.g., Unix machines, where there are no drive
letters, so I can see why the want to keep the code general.
There are many reasons why it's bad for a browser to make that sort
of assumption, but they are balanced by the fact that accepting bad
code will trick some people into thinking that the other browsers
are buggy, and so they will be less likely to support them, giving
the more lenient browsers a market advantage.
Hear, hear!
<script type="text/javascript" src="file:///C:/mydir/program.js">

The problem is that you need to change the file before uploading
to a server. The advantage is that it works locally :)

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Michael Winter]

On 2 Jan 2004 07:02:37 -0800, Lee <RE************ **@cox.net> wrote:

An URL beginning with a "/" is invalid. Since it isn't relative to
the URL of the current page, you must specify the protocol. IE lets
you get away with it, assuming that you mean the "file:" protocol.

That statement is incorrect as long as the document has a base URL; either
specified explicitly or derived from the document (it's file: or http:
URL). A URL beginning with a single forward slash would be parsed like so:

base: http://www.example.com/html/main.html

abs: /mydir/picture.jpeg -> http://www.example.com/mydir/picture.jpeg

If 'mydir' was a subdirectory in 'html', the relative URL should be:

rel: ./mydir/picture.jpeg ->
http://www.example.com/html/mydir/picture.jpeg

OR:

rel: mydir/picture.jpeg

You were correct though that a URL beginning with a forward slash is not
relative.

Using the file: scheme, the results should be similar: a single slash
would begin from the root directory of the current drive. However, RFC
1808 doesn't give examples for the file: scheme (probably due to numerous
and dissimilar filesystem formats).

<snip>

Mike
RFC 1808: http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1808.html

There is a list of examples towards the end of the document
(Section 5.1 - Normal Examples) that include a single, initial
forward slash.

--
Michael Winter
M.******@blueyo nder.co.invalid (replace ".invalid" with ".uk" to reply)

[Michael Winter]

On Fri, 02 Jan 2004 17:37:04 +0100, Lasse Reichstein Nielsen
<lr*@hotpop.com > wrote:

<script type="text/javascript" src="file:///C:/mydir/program.js">

The problem is that you need to change the file before uploading
to a server. The advantage is that it works locally :)

However, the simple thing is to mirror the directory structure on the
server on the development machine(s) as well (it's what I do). If you only
use relative URLs, with '../' used as necessary, you need to change
nothing, and it works locally, too. Of course, you need to plan your
directory structures carefully first, but shouldn't you always do that?

Mike

--
Michael Winter
M.******@blueyo nder.co.invalid (replace ".invalid" with ".uk" to reply)

[Christian Eyrich]

wylbur37 wrote:

I normally use Mozilla 1.4 on Windows XP Pro.
As I was developing some test webpages, I discovered that the SRC
parameter doesn't seem to work when a path is used with the filename.

In one example, when I want to run a JavaScript from an external file
(i.e., not inline), I would do the following ...

<SCRIPT LANGUAGE="JavaS cript" SRC="program.js "> </SCRIPT>

If "program.js " were in a different subdirectory than the .htm file
referring to it, the filename would have to be prefixed by the
pathname as follows ...

<SCRIPT LANGUAGE="JavaS cript" SRC="/mydir/program.js"> </SCRIPT>

But when I ran the above from within an .htm file loaded locally into
Mozilla, it did not work. (The result was as if the above code weren't
there). However, when I ran the identical code on Internet Explorer
(v.6), it worked.

"/mydir/program.js" is an absolute path. On your server this is ok if
the url is "www.yoursite.c om/mydir/program.js". But on the local machine
mydir is searched in the root dir - wherever this may be on Windows
machines (not C: at least on Win98).
Opera shows same results and I guess that's right.

Christian

[Lasse Reichstein Nielsen]

Michael Winter <M.******@bluey onder.co.invali d> writes:

However, the simple thing is to mirror the directory structure on the
server on the development machine(s) as well (it's what I do). If you
only use relative URLs, with '../' used as necessary, you need to
change nothing, and it works locally, too.
Yes, as long as the paths are in relation to the HTML file, it is
simple. However, if your javascript files contain paths as well, it
becomes difficult. E.g., this code in an external file:

function makeMyImg() {
var img = new Image();
img.src = "../images/myImage.png";
return img;
}

The problem is that when that code is called from an HTML page, the path
is taken relative to the HTML file, not the Javascript file. If you have
HTML files in different levels of directories, no relative path will
work for all of them. That makes absolute paths necessary for Javascript
files that are shared between different pages.
Of course, you need to plan your directory structures carefully
first, but shouldn't you always do that?

Absolutely. And always sooner than you expect :)

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[kaeli]

In article <hd**********@h otpop.com>, lr*@hotpop.com enlightened us
with...

The problem is that when that code is called from an HTML page, the path
is taken relative to the HTML file, not the Javascript file. If you have
HTML files in different levels of directories, no relative path will
work for all of them. That makes absolute paths necessary for Javascript
files that are shared between different pages.

Actually, I always use relative paths because of portability, and I had
to write a workaround to just this problem.
What I did was basically check where I was and write the source element
dynamically.

It was a server-side solution (coldfusion), but I bet it could be done
client-side as well, if needed.

--
--
~kaeli~
Condoms should be used on every conceivable occasion.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

[Grant Wagner]

Lasse Reichstein Nielsen wrote:

<script type="text/javascript" src="file:///C:/mydir/program.js">

The problem is that you need to change the file before uploading
to a server. The advantage is that it works locally :)

The solution is to install and run an httpd on the development PC, then you are
accessing the site using the same protocol and file paths as you will on the
real server.

--
| Grant Wagner <gw*****@agrico reunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/...ce/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/a...ence_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-deve...upgrade_2.html

[Richard Cornford]

"Christian Eyrich" <VJ**********@s pammotel.com> wrote in message
news:bt******** ****@ID-205057.news.uni-berlin.de...
<snip>

... But on the local machine mydir is searched in the
root dir - wherever this may be on Windows machines
(not C: at least on Win98).

<snip>

If you look at a file protocol URL on a Windows machine, such as -
file:///C:/mydir/program.js
- you may notice that the "file:" part is separated from the rest of
the URL by three slashes instead of the two that would usually be in
that location. The last of those three slashes represents the root
directory and as that is above the level of the drive letter it clearly
cannot represent any real location in the file system of a windows
machine. IE browsers seem to confuse the issue by applying the same path
rules that the OS uses when resolving file names.

Richard.