Closed Bug 167281 Opened 22 years ago Closed 19 years ago

event.preventDefault() on textbox element not working properly

Categories

(Core :: DOM: Events, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: dnfesp, Assigned: bryner)

Details

Attachments

(3 files)

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? 
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...
QA Contact: rakeshmishra → trix
event.preventDefault() doesn't works with INPUT and TEXTAREA html tags
(Linux, build id: 2002122105)
javascript code:

function handleEvent(e) {
 e.preventDefault();
}

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;
try this:

function handleEvent(e) {
 return false;
}
Any chance of answering the question from comment 3?
> 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
Status: UNCONFIRMED → NEW
Component: Event Handling → XP Toolkit/Widgets: XUL
Ever confirmed: true
QA Contact: trix → shrir
Can anyone show me an example where this works in HTML for <input type=text>
or <textarea> ?
In a regular html page it works as expected.
Actually, I meant "show me where this works in HTML for addEventListener", but
anyways.

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">
<script>
  function x(e) {
    window.status = "x - " + (new Date()).getTime();
    e.preventDefault();
  }
  var isCapturing = true;
  window.onload = function () {
    document.getElementById("x").addEventListener("keypress", x, isCapturing);
  };
</script>
<textbox id="x" type="text"/>
</window>
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 
behaviour. 

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
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

->bryner
Assignee: saari → bryner
dupe of 179974?
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.... ;)
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: