Closed
Bug 167281
Opened 22 years ago
Closed 19 years ago
event.preventDefault() on textbox element not working properly
Categories
(Core :: DOM: Events, defect)
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.
Comment 1•22 years ago
|
||
Are you using a bubbling or capturing handler?
Reporter | ||
Comment 2•22 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.
Comment 3•22 years ago
|
||
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...
Updated•22 years ago
|
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;
Reporter | ||
Comment 5•22 years ago
|
||
try this: function handleEvent(e) { return false; }
Reporter | ||
Comment 7•22 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
Comment 8•22 years ago
|
||
Over to XUL.
Assignee: joki → hyatt
Status: UNCONFIRMED → NEW
Component: Event Handling → XP Toolkit/Widgets: XUL
Ever confirmed: true
QA Contact: trix → shrir
Comment 9•22 years ago
|
||
Can anyone show me an example where this works in HTML for <input type=text> or <textarea> ?
Reporter | ||
Comment 10•22 years ago
|
||
In a regular html page it works as expected.
Comment 11•22 years ago
|
||
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>
Comment 12•22 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 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
Comment 13•22 years ago
|
||
Comment 14•22 years ago
|
||
Comment 15•22 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 ->bryner
Assignee: saari → bryner
Comment 16•22 years ago
|
||
dupe of 179974?
Comment 17•22 years ago
|
||
No
Comment 18•19 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 ...
Comment 19•19 years ago
|
||
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.
Description
•