firefox doesn't like the IE specific 'event' identifier and just quits running script

[code_wrong]

Hi
Firefox does not support the IE specific 'event' identifier and just quits
running the script.
..... even though the identifier only turns up in code marked for IE only ...

Does this seem reasonable?

The script is here:
http://www.lunds.us/private/coolclock.htm

This is the offending bit of script:
function Mouse(evnt){
ymouse =
(ns)?evnt.pageY +ClockFromMouse Y-(window.pageYOf fset):event.y+C lockFromMouseY;
xmouse = (ns)?evnt.pageX +ClockFromMouse X:event.x+Clock FromMouseX;
}Is there a neat workaround?chee rs, cw

[Fred Oz]

code_wrong wrote:

Hi
Firefox does not support the IE specific 'event' identifier and just quits
running the script.
.... even though the identifier only turns up in code marked for IE only ...
Your script may not doing what you think it is. If I'm running
Firefox, what value will the global variables "ie" and "ns" have
after this:

ns=(document.la yers);
ie=(document.al l);

If you guessed "undefined" , you're right. So when you go to
execute your "code marked for IE only" (excuse trimming):

ymouse = (ns)?evnt.pageY +... : event.y+ClockFr omMouseY;

What you are testing is not whether "ie" is true but whether
"ns" is true. Since ns is undefined, the test returns false and
your code tries to execute the stuff you've "marked for ie only".

Does this seem reasonable?

Depends on what your view of what is "reasonable ". Using
detection of a single feature to infer the UA and hence
support for an entire environment is fatally flawed (as you've
discovered). That is probably unreasonable.
The script is here:
http://www.lunds.us/private/coolclock.htm

This is the offending bit of script:
Offensive? :-)
function Mouse(evnt){
ymouse =
(ns)?evnt.pageY +ClockFromMouse Y-(window.pageYOf fset):event.y+C lockFromMouseY;
xmouse = (ns)?evnt.pageX +ClockFromMouse X:event.x+Clock FromMouseX;
}Is there a neat workaround?chee rs, cw

Yes. Ditch browser detection completely. Use feature
detection. Detect and use W3C stuff first, if it fails, try
other (usually IE) stuff.

To fix your event issue,

function Mouse(evnt){
var e = evnt || window.event;

if (e.clientY)
ymouse = e.clientY+Clock FromMouseY;

} else if (e.y) {
ymouse = e.y+ClockFromMo useY;

} else if (e.pageY) {
ymouse = e.pageY+ClockFr omMouseY-(window.pageYOf fset);
}
}

Untested, but IIRC clientX and clientY are the W3C properties
you are looking for that are equivalent to x and y. They are
supported by IE 6 (and maybe earlier), testing for them first
will suit perhaps 99% of browsers (i.e. only old IE and old
Netscape will want something else).
--
Fred

[Fred Oz]

Fred Oz wrote:
[...]

Ooops, left out xmouse. Only need to feature detect once (it's
very likely that if clientY is supported, so is clientX...):

function Mouse(evnt){
var e = evnt || window.event;

if (e.clientY)
ymouse = e.clientY+Clock FromMouseY; xmouse = e.clientX++Cloc kFromMouseX;
} else if (e.y) {
ymouse = e.y+ClockFromMo useY; xmouse = e.x+ClockFromMo useX;
} else if (e.pageY) {
ymouse = e.pageY+ClockFr omMouseY-(window.pageYOf fset); xmouse = e.pageX+ClockFr omMouseX; }
}

--
Fred

[Richard Cornford]

Fred Oz wrote:

Fred Oz wrote:
[...]
Ooops, left out xmouse. Only need to feature detect once (it's
very likely that if clientY is supported, so is clientX...):

function Mouse(evnt){
var e = evnt || window.event;

if (e.clientY)
ymouse = e.clientY+Clock FromMouseY;

xmouse = e.clientX++Cloc kFromMouseX;

<snip>

It probably is valid to assume that an event object supporting clientX
will also support clientY. However, The style of testing you have
applied is problematic because the values being referred to are
primitive and so a type-converting test will produce results that depend
on the actual value. While an unsupported property will be undefined and
so type-convert to boolean false a numeric zero value (or an empty
string) will also type-convert to false. Where a property to be
tested/verified is an object or function, that will be undefined when
not implemented (and possibly null where supported but not present in
context), type-converting tests are probably optimum. Where a property
is expected to have a primitive value when implement a - typeof - test
is often necessary to produce reliable results.

Unfortunately, - typeof - testing is less efficient, but it can be
arranged that the testing does not need to be repeated each time a value
is read; the initial assumption still applies, if an event object
implements clientX the first time it is tested then the chances are good
that all (mouse related) event will also implement clientX, etc.

Richard.

[Mark Preston]

code_wrong wrote:

Firefox does not support the IE specific 'event' identifier and just quits
running the script.
.... even though the identifier only turns up in code marked for IE only ...

Does this seem reasonable?

Frankly, yes it does. Consider this:-

You visit Russia. While there, you go to Lenin's Tomb and ask the guide
to explain how to see his personal effects. You ask in French. Do you
get upset because the guide only speaks Russian?

Javascript is a standard language and an interpreter using that standard
language recognises the standard terms of the language. If you throw in
terms that are not part of the languange, then it is no suprise when
they turn out to be meaningless.

[Fred Oz]

Richard Cornford wrote:

Fred Oz wrote:

Fred Oz wrote: [...]

function Mouse(evnt){
var e = evnt || window.event;

if (e.clientY)
ymouse = e.clientY+Clock FromMouseY;

[...]
It probably is valid to assume that an event object supporting clientX
will also support clientY. However, The style of testing you have
applied is problematic because the values being referred to are
primitive and so a type-converting test will produce results that depend
on the actual value. While an unsupported property will be undefined and
so type-convert to boolean false a numeric zero value (or an empty
string) will also type-convert to false. Where a property to be
tested/verified is an object or function, that will be undefined when
not implemented (and possibly null where supported but not present in
context), type-converting tests are probably optimum. Where a property
is expected to have a primitive value when implement a - typeof - test
is often necessary to produce reliable results.

[...]

Thank you Richard ;-)

In case the OP missed it...

function Mouse(evnt){
var e = evnt || window.event;

if (typeof(e.clien tY)){
ymouse = e.clientY+Clock FromMouseY;
...
}

If clientY is supported, typeof(e.client Y) will return "number"
or something other than "undefined" I guess and hence be
evaluated to true (or not false). I don't have a browser that
doesn't support it so untested .

--
Fred