Opera 7.54 Javascript Errors

[Mark Pappert]

I've got a linked 'common.js' file that contains one function, on IE
and Firefox everything works as expected. However, Opera generates the
following error:


http://www.mdocs.ca/scripts/common.js
Unknown context
Syntax error while loading (line 61)

-^


line 61 is the close } of the function?

Now I'm not sure if this is related to my other problem, but when I
click the Opera Test link (to create the popup) it generates this
error:


http://www.mdocs.ca/alpha_v1d814.htm
Javascript URL thread:
"javascriptopupWindow('http://www.mdocs.ca/feedback.htm','feedback',460,415,0,0,'yes','no','no','n..."
Error:
name: ReferenceError
message: Statement on line 1: Reference to undefined variable: No such
variable 'popupWindow'
Backtrace:
In unknown script
popupWindow("http://www.mdocs.ca/feedback.htm", "feedback", 460,
415, 0, 0, "yes", "no", "no", "no");


It says that it can't reference the variable 'popupWindow' when in
fact, its a function that is defined in the linked common.js file.
Any ideas?

Cheers!
M.

 

[Michael Winter]

I've got a linked 'common.js' file that contains one function, on IE
and Firefox everything works as expected. However, Opera generates the
following error:


http://www.mdocs.ca/scripts/common.js
Unknown context
Syntax error while loading (line 61)

-^


line 61 is the close } of the function?

<!-- mdocs.ca Common Scripts v0.1 | Copyright (c) 2004, Immergis
Corporation. All Rights Reserved -->

I'm curious to know why you're using SGML comments in a JavaScript file.
Use SGML delimiters in HTML and

// Single line
/* or
Multi-line */

comments in scripts. Removing the final SGML comment, or replacing it with
an equivalent script comment allows the script to run, but *ALL* of them
should be replaced.

Now I'm not sure if this is related to my other problem, but when I
click the Opera Test link (to create the popup) it generates this
error:

If the script doesn't load properly, why would the function load properly?
Of course, it doesn't help that you have more inappropriate comment types
within the function, too.

[snip]

Now to the rest of the script...

resizable[ optional; value = yes|(no) ]

Am I to assume that your notation implies the resizable option defaults to
"no"? If so, it shouldn't. There is no reason why you should restrict the
users ability to resize the window. For one, unless your specifying exact
sizes (which you shouldn't), you can't tell how large the users browser
text will be and whether that will cause the content to be too big for
your window. There's another (not so significant) reason that I'll come to
later.

At least the scrollbars default to 'yes', however I notice that you
disable them in the call. Again: don't!

isIE = new Boolean(false);

Simply

isIE = false;

will to, however

if (navigator.userAgent.indexOf("MSIE")!=-1) { isIE = true; }
if (navigator.userAgent.indexOf("Opera")!=-1) { isIE = false; }

is nonsense. You cannot reliably detect the browser in use based upon the
userAgent string. Most browsers, even IE, can have it set to whatever the
user wants, and there are plenty of browsers that fake other major browser
types.

if (isIE == true) {

It is simpler to write

if(isIE) {

<!-- COMMENT[MP]: Adjust Width/Height to Reflect that IE Measures
Window Size and not Inner Size -->
width = width + 6; height = height + 32

<!-- COMMENT[MP]: Adjust Window Size to Account for for WinXP|SP2;
If Status is 'NO' -->
if ((navigator.userAgent.indexOf("SV1")!=-1) && (status = 'no'))
{ height = height + 20; }

More nonsense; both the comment types and the code. Your adjustments are
based upon the assumption that every Windows system in the world is the
same as yours. It isn't. The size of the title bar, borders, status bar -
in fact, virtually every component - varies according the to applied
theme. The only way you can determine the actual sizes is through a direct
call to the Win32 API, which you obviously can't do from within a script.

This is the other reason that I mentioned above regarding sizing. If your
estimates are completely wrong, and they could be, you'll be creating a
window too small for the content, with no way to resize or scroll.

win = window.showModelessDialog(sURL,sArguments,sFeatures);

That's all you should really need to test for. If the browser supports
showModelessDialog(), it should support everything you've done to
configure the call. So, change

if (isIE == true) {

to

if(window.showModelessDialog) {

to get a more reliable idea of what the browser can do. This is called
feature testing: check that the properties and methods you want to execute
are available, and use them if they are. The group FAQ can tell you more.

winLeft = (screen.availWidth - width) / 2;
winTop = (screen.availHeight - height) /2;

What if the user has multiple monitors?

Of course, why you need those contact pages in another window is another
fine question. They will do just as well presented as normal pages.

In a world where the number of pop-up blockers, both conservative and
indescriminate, are growing every day, opening new windows (thought
annoying enough anyway) is a bad idea.

Finally, you ought to review the group FAQ regarding JavaScript links.
They make a site dependent for no good reason, cause various other
(unrelated) problems, and should be avoided in all but a few cases.

Mike

 

[Ivo]

I've got a linked 'common.js' file that contains one function, on IE
and Firefox everything works as expected. However, Opera generates the
following error:


http://www.mdocs.ca/scripts/common.js
Unknown context
Syntax error while loading (line 61)

-^


line 61 is the close } of the function?

Remove the SGML comments from the .js file.
This is a SGML comment:
<!-- All Rights Reserved -->

But a javascript comment looks like this:
// All Rights Reserved

or this:
/* All Rights Reserved */

After you have cleaned up the file, you may want to run it through the
javascript lint at http://www.crockford.com/javascript/jslint.html to check
for other problems.

Now I'm not sure if this is related to my other problem, but when I
click the Opera Test link (to create the popup) it generates this
error:


http://www.mdocs.ca/alpha_v1d814.htm
Javascript URL thread:
"javascriptopupWindow('http://www.mdocs.ca/feedback.htm','feedback',460,41
5,0,0,'yes','no','no','n..."
Error:
name: ReferenceError
message: Statement on line 1: Reference to undefined variable: No such
variable 'popupWindow'

Of course not. Poor Opera hasn't understood a single letter from your .js
file.
Also putting javascript in the href of a link is usually not a good idea.
See the FAQ.
<URL: http://jibbering.com/faq >

 

[Dr John Stockton]

JRS: In article <opscrgyacgx13kvk@atlantis>, dated Sun, 15 Aug 2004
06:41:40, seen in Michael Winter <M.Winter@bl
ueyonder.co.invalid> posted :

Finally, you ought to review the group FAQ regarding JavaScript links.
They make a site dependent for no good reason, cause various other
(unrelated) problems, and should be avoided in all but a few cases.

Does that mean that <a href="javascript:testF()">Test</a> is
deprecated (testF being a function)?

 

[Randy Webb]

JRS: In article <opscrgyacgx13kvk@atlantis>, dated Sun, 15 Aug 2004
06:41:40, seen in Michael Winter <M.Winter@bl
ueyonder.co.invalid> posted :




Does that mean that <a href="javascript:testF()">Test</a> is
deprecated (testF being a function)?

Its not so much that its deprecated, it creates a javascript dependency
and is known to cause problems with animated gifs.

Both issues can be solved by:

<a href="jsDependency.html" onclick="testF();return false">Test it</a>

Where jsDependency.html can be a page that explains the test, maybe even
provide the function details.

 

[Lasse Reichstein Nielsen]

Does that mean that <a href="javascript:testF()">Test</a> is
deprecated (testF being a function)?

If the function returns "undefined", that is, the URL is only used
for its side effect, and not as a way to create a replacement for
the current page, then it should be deprecated. It is misuse of the
"a" tag, since the URL doesn't refer to another page.

Instead, one could (and should) use:
<input type="button" value="Test" onclick="testF()">
Buttons are meant to have an effect when pressed. Links are meant
to lead to another resource. If, for some reason, using a button
is not acceptable, then at least using
<a href="youNeedJS.html" onclick="testF();return false;">Test</a>
is better, since it gives a default behavior if Javascript is
disabled (even if that behavior is just to lead to a page that
explains that Javascript is required)


If "testF" actually returns the HTML of a new page, then the
"javascript:" scheme URL is used correctly. However, it still has no
reasonable behavior if Javascript is not available, and should be
avoided for that reason alone.


It's not officially deprecated (since it was never officially defined
anyway), but I'd recommend against it when used on the internet (where
~10% are surfing without Javascript according to some statistics, although
that number seems to be dropping).

/L

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Mon, 16 Aug 2004
02:24:41, seen in Lasse Reichstein Nielsen

If the function returns "undefined", that is, the URL is only used
for its side effect, and not as a way to create a replacement for
the current page, then it should be deprecated. It is misuse of the
"a" tag, since the URL doesn't refer to another page.

It has no return statement, the function being used for side-effect.

If "testF" actually returns the HTML of a new page, then the
"javascript:" scheme URL is used correctly. However, it still has no
reasonable behavior if Javascript is not available, and should be
avoided for that reason alone.

It's reasonable to expect that javascript is available to the reader of
that page, whether or not it is currently operational, since the
document in question describes itself, more or less, as a javascript
FAQ. Not, of course, the JL/RC one.


Perhaps Martin would be the best person to look into improving that FAQ,
which also has an ingenious, but unsymmetrical, rounding-to-decimal-
string routine.

There's a certain charm in a FAQ which, in referring to presenting a
lastModified date in the usual local form, chooses Jan 1st for an
example - no, it's worse than that, it shows the actual live string, and
the page was edited on Jan 1st. A fresh local copy shows me
(unconverted)
document.lastModified: 08/16/04 21:40:24


I tried Tidy on it; and, for comparison, on our FAQ. Early in our sec
2.3, it objects to the space before http:// ; it likes theirs less.