Cancel Event in Firefox

R

ryanmhuc

I have a function which needs to cancel the input into a text field on
a form. I cancel the event in IE fine and the text does not get
entered. But for firefox (1.0) I cancel the event and the text still
gets entered.

I've stripped the function down just to try to get it to work in
Firefox. The alert does happen on the keydown event so it should be
cancellable.

function formatInput(e){
if (e.cancelable){
e.preventDefault()
alert("Event is cancelable")
}
}

How can I cancel the input??
 
R

Rob

I have a function which needs to cancel the input into a text field on
a form. I cancel the event in IE fine and the text does not get
entered. But for firefox (1.0) I cancel the event and the text still
gets entered.

I've stripped the function down just to try to get it to work in
Firefox. The alert does happen on the keydown event so it should be
cancellable.

function formatInput(e){
if (e.cancelable){
e.preventDefault()
alert("Event is cancelable")
}
}

How can I cancel the input??

Why not just disable the text field, blur it, and erase whatever was
entered?
 
R

ryanmhuc

Cause I do not want to disable it. That was a stripped function to try
to get it to work. I only want to cancel the event on certain keyCodes
not ALL keyCodes. You can't erase a delete, or an End or a Home, etc.
Anyone know how to cancel the event so it does not continue with the
keyCode pressed?
 
V

VK

Cause I do not want to disable it. That was a stripped function to try
to get it to work. I only want to cancel the event on certain keyCodes
not ALL keyCodes. You can't erase a delete, or an End or a Home, etc.
Anyone know how to cancel the event so it does not continue with the
keyCode pressed?

The main rule is: you have to return false from the event handler to
cancel an event. The code below works for FF 1.0.7

Please not that:
1) In intrisic event handlers (textbox txt1) you have to return false
*from the handler itself* - not from the function called by the
handler. I guess that was your original problem.

2) There is a nasty bug in current versions of FireFox. Typing any text
in a textbox leads to the security exception (you can check the
JavaScript console). It doesn't break the script, but it causes a small
delay in the execution. If you additionally pass each input event
through a custom check, this delay may get noticable. The only
workaround I'm aware of in setting autocomplete to false; but it's not
always suitable.

<html>
<head>
<title>Test</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<script type="text/javascript">
/* Script for FireFox and Gesko-based only */

function f(e) {
if (String.fromCharCode(e.which).
toUpperCase() == 'A') {
return false;
}
else {
return true;
}
}

function init() {
document.forms[0].elements['txt2'].onkeypress = f;
}

window.onload = init;
</script>
</head>

<body>

<form method="post" action="">
<input type="text" autocomplete="false" name="txt1" onkeypress="return
f(event)">
<input type="text" autocomplete="false" name="txt2">
</form>

</body>
</html>
 
R

ryanmhuc

VK,
Thanks for the reply. I am aware that I can stop it by returning
false on the actual event attribute. But my issue is that the function
is attached to the event via javascript and so unable to return a value
as JavaScript states.

So what you saying is the FireFox documentation on e.cancelable
e.preventDefault() are completely BS? The preventDefault should stop
the normal functionality from occuring but does not??? Although I
believe you I just don't understand why this is so.

Is there anyway around this. The function MUST be attached via
JavaScript so returning false is out of the question. Thanks for any
help you could provide.
 
V

VK

So what you saying is the FireFox documentation on e.cancelable
e.preventDefault() are completely BS? The preventDefault should stop
the normal functionality from occuring but does not??? Although I
believe you I just don't understand why this is so.

It is not BS (at least not all of it :)
Simply window.status is a *legacy* interface from Netscape. And usually
when you are dealing with legacy you have to forget any common as well
as any particular sense and just do what is working.

Status change requires return true from the same context where the
change has been made:
window.status = myText;
return true;

These statements have to be in this order and within the same context.
There is no any reason in it, like there is no reason in the hill
behind my window. It just here.
You may do not like Microsoft, but one thing you have to give them a
credit for (?): if a standard and the common sense are in
contradiction, they choose the common sense.

Intrinsic event handlers are really anonymous functions. So fragment
like:
<a href="foo.html" onmouseover="window.status='Hello!';return true;"...

in the reality is:
<a href="foo.html" onmouseover="
function anonymous() {
window.status='Hello!';
return true;
}"...
and it's fine

But
<a href="foo.html" onmouseover="myFunction('Hello!');"...
in the reality is:
<a href="foo.html" onmouseover="
function anonymous() {
myFunction('Hello!');
}"...
And now you can see clearly that it is not matter what will you return
from myFunction(): function anonymous() will still return undefined to
the handler.

Now you can guess that the programmed handler:
myHref.onmouseover = myFunction;
in the reality is a reproduction of the same situation
but even in worse case because you are left w/o possibility to
pass arguments:
myHref.onmouseover= function() {myFunction();}

And the only way I can think of to overpass this legacy crazyness is to
use anonymous function right on the handler:
myHref.onmouseover = function() {
window.status = 'Hello!';
return true;
}

The last finally works for FF (if "Change status bar text" option is
enabled).
 
T

Thomas 'PointedEars' Lahn

VK said:
Simply window.status is a *legacy* interface from Netscape.

It is not. It is a proprietary, yet widely implemented, property
of a (proprietary, yet widely implemented) host object.


PointedEars
 
V

VK

Thomas 'PointedEars' Lahn wrote:
It is not. It is a proprietary, yet widely implemented, property
of a (proprietary, yet widely implemented) host object.

I'm wondering what *proprietary* means for you? Something that it was
not originally invented/proposed by W3C? Then the every single piece of
HTML/DOM/JavaScript is proprietary and used to deliver information over
proprietary media (WWW) to proprietary interface (browser). No one of
these things is W3C discover or achievement. W3C is just a more-or-less
reliable standartisation unit, not a development lab.

Data Binding is proprietary, XPConnect is proprietary. Whatever was
made before any smell of W3C is *legacy*.
 
T

Thomas 'PointedEars' Lahn

You really want to learn how to quote properly.
I'm wondering what *proprietary* means for you?

Essentially it means to me (and others) "not specified in or by a
public standard, implemented only by one or more specific vendors".
Something that it was not originally invented/proposed by W3C?

No. Something not specified by W3C, iff there is a W3C standard
for it. You may replace "W3C" with the name of any acknowledged
standardization body.
Data Binding is proprietary, XPConnect is proprietary.
Correct.

Whatever was made before any smell of W3C is *legacy*.

No. And "Legacy" implies "obsolete".


PointedEars
 
R

ryanmhuc

VK,
I love your view on the common sense verse standards! Do you know of
a way to cancel the event with a function that is attached using the
addEventListener in FireFox? Or is that asking too much? I've been
trying but no cigar. Thanks again for all your help on this.

Ryan
 
T

Thomas 'PointedEars' Lahn

VK said:
You may do not like Microsoft, but one thing you have to give them a
credit for (?): if a standard and the common sense are in
contradiction, they choose the common sense.

Which is why it (probably) took IE_7_ to achieve basic Web standards.
You made my day.


PointedEars
 
V

VK

VK,
I love your view on the common sense verse standards! Do you know of
a way to cancel the event with a function that is attached using the
addEventListener in FireFox? Or is that asking too much? I've been
trying but no cigar. Thanks again for all your help on this.

As much as I can tell (I'm all in debugging of my new prog right now so
no testing) addEventListener will not work by definition because

ahref.addEventListener('mouseover',myfunc,false)

is

ahref.onmouseover = function anonymous() {myfunc();}

and see my previous answer.

This deadlock happened during the FF growthup when they did not dare to
make a fart w/o W3C written permission. This year the child finally
reached the age to "understand how stupid really parents are": so you
may file a complain to bugzilla.mozilla.org and have a hope that they
will fix it as Microsoft did.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,774
Messages
2,569,596
Members
45,143
Latest member
DewittMill
Top