event.preventDefault() on textbox element not working properly




DOM: Events
16 years ago
14 years ago


(Reporter: Daniel Fernandez, Assigned: Brian Ryner (not reading))


Windows 2000

Firefox Tracking Flags

(Not tracked)



(3 attachments)



16 years ago
I was trying to 'return false;' or 'event.preventDefault()' when the user
presses an invalid character, with the onkeypress event this would normally
prevent the character appear into the input field of a regular html form, but
with the xul textbox element it doesn't works like that, the character pressed
appears so I can't use this type of input validation.
Are you using a bubbling or capturing handler? 

Comment 2

16 years ago
I'm using bubbling handling

I think this issue is related with the textbox widget, because when using common
html input, this behaviour works fine.
Does it work if you use a capturing handler?  I bet the problem is that the 
event does not bubble out to the enclosing XUL widget till after the letter has 
been entered...


16 years ago
QA Contact: rakeshmishra → trix

Comment 4

16 years ago
event.preventDefault() doesn't works with INPUT and TEXTAREA html tags
(Linux, build id: 2002122105)
javascript code:

function handleEvent(e) {

function init() {
 var i1 = document.getElementById('i1'); // input tag
 var i2 = document.getElementById('i2'); // textarea tag
 i1.addEventListener('keydown', handleEvent, false);
 i2.addEventListener('keydown', handleEvent, false);
window.onload = init;

Comment 5

16 years ago
try this:

function handleEvent(e) {
 return false;
Any chance of answering the question from comment 3?

Comment 7

16 years ago
> Does it work if you use a capturing handler?

No it doesn't works either, I have tested it with a slightly modified version of
the code above using the following alternatives in the handler function: return
false, e.preventDefault(), e.preventCapture(), e.stopPropagation()

none of them works

sorry for the late answer, I have been very busy
Over to XUL.
Assignee: joki → hyatt
Component: Event Handling → XP Toolkit/Widgets: XUL
Ever confirmed: true
QA Contact: trix → shrir

Comment 9

16 years ago
Can anyone show me an example where this works in HTML for <input type=text>
or <textarea> ?

Comment 10

16 years ago
Created attachment 110536 [details]
html file showing what must be work for textboxes

In a regular html page it works as expected.

Comment 11

16 years ago
Actually, I meant "show me where this works in HTML for addEventListener", but

This works in XUL, if using a capturing listener for keypress. Other variations
do not appear to prevent the key from being entered.

<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
<window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
  function x(e) {
    window.status = "x - " + (new Date()).getTime();
  var isCapturing = true;
  window.onload = function () {
    document.getElementById("x").addEventListener("keypress", x, isCapturing);
<textbox id="x" type="text"/>

Comment 12

16 years ago
I don't think this is a XUL bug per se. For the equivalent testcase in HTML, 
where the event listener is added to a div containing an <input> (i.e., in 
XUL, the <html:input> is wrapped inside the xul textbox), I get the same 

The only case that does the preventDefault successfully is for a capturing 
listener for 'keypress'. For 'keyup' and 'keydown', capturing or not, and 
for 'keypress' when not capturing, the key value is displayed in the input
text field. I'll attach XUL and HTML examples.

-> DOM Events
Assignee: hyatt → saari
Component: XP Toolkit/Widgets: XUL → DOM Events
QA Contact: shrir → vladimire

Comment 13

16 years ago
Created attachment 110544 [details]
HTML testcase -- 6 cases of addEventLister for <input type='text'> for (capture|non-capture) X ('keypress'|'keydown'|'keyup')

Comment 14

16 years ago
Created attachment 110545 [details]
XUL testcase -- 6 cases of addEventLister for <textbox/> for (capture|non-capture) X ('keypress'|'keydown'|'keyup')

Comment 15

16 years ago
yes, this is one big reason we did the new event pass work. Need to complete the
loop now and start moving listeners (in this case text fields) to the proper pass

Assignee: saari → bryner

Comment 16

16 years ago
dupe of 179974?

Comment 18

14 years ago
It seems to me that "event.preventDefault()" is in fact preventing default
action in trunk Firefox builds now (specifically the 3 Mar 05 build).  I've got
page code that for some time has unwittingly exploited the fact that "key down"
events to input and textarea tags were handled by the "native" handlers even
after calling preventDefault(), and that code stopped working (or, perhaps,
started working ...) in the trunk build.

For whatever that's worth ...
The behavior for HTML changed due to bug 167145 being fixed.  The XUL issue also
worksforme; not sure why, but.... ;)
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.