Open
Bug 221489
Opened 22 years ago
Updated 3 years ago
can't stop event bubbling when using function keys, browser keep on doing normal behavior
Categories
(Core :: DOM: Events, defect, P5)
Tracking
()
UNCONFIRMED
People
(Reporter: duckmandrunk, Unassigned)
References
()
Details
Attachments
(1 file)
|
8.82 KB,
text/html
|
Details |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830
When mapping the function keys(F1-F12) using javascript to a custom action, in
previous versions
(prior to 1.5) the normal behavior of the browser could be stoped. In example
using the F3 key the search pop-up could be restrained from apearing by calling
<JavaScript>event.cancelBubble = true;</JavaScript> after the interception of
the event with <JavaScript>window.addEventListener(...,...,...)</JavaScript>.
Now the search pop-up shows up. But is it realy a bug or is it that this
behavior has been corrected to stop this sort of function keys remapping ?
Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Actual Results:
The call to the normal behavior is still done.
Expected Results:
The browser should not resume to it's normal operation after the bubbling has
been stoped.
<html>
<head>
<script language="JavaScript" type="text/javascript">
var fKeysID = new
Array("F1","F2","F3","F4","F5","F6","F7","F8","F9","F10","F11","F12");
window.addEventListener("keypress", checkFKeys,true);
/*
Fkeys are (F1=112)+nFX
*/
function checkFKeys(e){
var oEvent = e;
var intKeyCode = oEvent.keyCode;
if(intKeyCode > 111 && intKeyCode < 124){
// alert("KeyPressed = " + fKeysID[intKeyCode-112]);
document.getElementById("fOUT").value = fKeysID[intKeyCode-112];
oEvent.cancelBubble = true;
//Other tries
//oEvent.preventBubble();
//oEvent.preventCapture();
//oEvent.stopPropagation();
}
return false;
}
</script>
</head>
<body>
Test Page<br>
<form>
Key pressed<input type="text" size=6 id="fOUT">
</form>
</body>
</html>
Comment 1•22 years ago
|
||
Does preventDefault() also not work?
Comment 2•20 years ago
|
||
No, that doesn't work also.
There doesn't seem to be a way to stop normal browser behavior for keypressing.
Comment 3•20 years ago
|
||
I added next codes at first of checkFKeys(e) in sample code.
> var msg = "e=" + e + "\n" ;
> for (x in e) { msg += x + ":" + e.x + "\n" ; }
> alert(msg);
Then I obtained following result with Mozilla suite 2005070105-trunk/Win-2K.
> e=[object KeyboardEvent]
> type:undefined
> target:undefined
> (snip)
> stopPropagation:undefined
> preventDefault:undefined
> (snip)
> charCode:undefined
> keyCode:undefined
> (snip)
John Silver, what is set in oEvent.keyCode property of the event object passed
to your event handler?
Boris, is enhancement on "Key board event" in progress on DOM event model or
Mozilla's implementation?
Comment 4•20 years ago
|
||
KeyboardEvent is a Mozilla thing -- DOM2 Events doesn't do key events at all,
and DOM3 Events doesn't really exist.
Comment 5•20 years ago
|
||
Correction of Comment #3.
- e.x have to be e[x]
(I was writing REXX just before writing the JavaScript... Sorry for spam.)
When I pressed F1 key, event object was as follows.
(Mozilla suite 2005070105-trunk/Win-2K)
> (F1 key, Cature Phase)
> e=[object keyboardEvent]
> type=kepress
> target:[object HTMLHtmlElement]
> currentTarget:[object Window]
> eventPhase:1
> bubbles:true
> cancelable:true
> (snip)
> stopProagation:function stopProagation() { [native code] }
> preventDefrault:function preventDefrault() { [native code] }
> (snip)
> charCode:0
> keyCode:112
> (snip)
And I added next to reporter's test case:
> window.addEventListener("keypress", checkFKeys_x,false);
Overall test flow is as follows;
(during load)
window.addEventListener("keypress", checkFKeys,true);
(Case-1) checkFKeys does alert only
(Case-2) checkFKeys calls stopPropagation()
window.addEventListener("keypress", checkFKeys_x,false);
checkFKeys_x does alert only
(F1 key is pressed.)
When (Case-1), checkFKeys_x was invoked.
But when (Case-2) checkFKeys_x was not invoked.
=> WORKSFORME
(In reply to comment #2)
> No, that doesn't work also.
Is it for "preventDeafult()" instead of for "stopPropagation()"?
As seen above my result, target object when F1 is pressed is HTML element.
> target:[object HTMLHtmlElement]
> currentTarget:[object Window]
So preventDeafult() means "cancel of default on_keypress action of HTML
element", then preventDeafult() does nothing in this test case.
Martijn Wargers, how about stopPropagation()?
Comment 6•20 years ago
|
||
(In reply to comment #5)
> Martijn Wargers, how about stopPropagation()?
That's also in the url testcase, that also doesn't prevent the default action
from happening.
Comment 7•20 years ago
|
||
(In reply to comment #6)
> That's also in the url testcase, that also doesn't prevent the default action
> from happening.
As you say "url testcase", I tried to test on <div><a
onkeypress="...">...</a></div>, with addEvenetListner("keypress"), for both
<div> and <a>, and for both Capture-Phase and Bubble-Phase.
But onkeypress script for <a> was not invoked when mouse is placed above <a> and
F1 is pressed.
Then I put onClick="return false;" for <a>, then I tested again.
Overall sceinario is as follows.
- <div><a href="..." onClick="return false;" onkeypess="Sctipt_X();"></a></div>
- addEventListner was issued for all of;
- Script-DIV-A as Capture-Phase Listner for <div>
- Script-DIV-B as Bubble-Phase Listner for <div>
- Script-LNK-A as Capture-Phase Listner for <a>
- Script-LNK-B as Bubble-Phase Listner for <a>
Result was as follows.
(1) Click <a> => No branch by <a href> because of onClick="return false;"
=> focused on <a>
(2) Press F1 key => All four event-listners was invokded.
But onkeypress="..." of <a> was not invoked.
(3) When <a> is cliked again, <a onkeypress="Sctipt_X();"> was executed,
then <a href="..."> was ecxecuted.
My funny results possibly have relation to result in your "the url testcase".
Martijn Wargers, can you attach your "the url testcase"?
(Simplified test case is preferable.)
Comment 8•20 years ago
|
||
(In reply to comment #2 and comment #6)
Martijn Wargers, deos your "the url testcase" mean the site specified in the
"URL:" field of this bug?
If yes, script in the site never works due to JavaScript error - function "doe"
is not defined.
If not, what object's event-lisner at what phase(Capture phase or Bubble phase)
issues stopPropagation() or preventDefault()?
What object is the "target" object for the event?
What is the "default action/event" which has to be prevented in your case?
Comment 9•20 years ago
|
||
If "not canceled action" is "Find As You Type when key is pressed at a LINK", I
probably re-created reporter's case.
(Please ignore my comment #7. Reasons of funny result was my preference setting
- Find As You Type is disabled, and extention, and bug in my script.)
(Test Procedure)
(1) Enable "Find As You Type"
(2) Click "Clear textarea" button
(3) Highlight text before a LINK (link1/2/3_True/False) by mouse drag
(4) Press "Tab" key in order to move focus on the link
(5) Press "q" or "q" or "Tab" or "Shift/Tab" or "F3"
(links in test case doesn't contain "w".)
=> Trace data by eventListner and onKeypress handler is written
As I don't know affect of return code by onKeypress event handler of the LINK,
Two cases are prepared - linkN_True : return true, linkN_False : return false.
(Result in my quick test. Only "retun true" case.)
(1) Test in DIV1 :
When a LINK(which is placed after the focused LINK) contains pressed key's
character, "q" in my test case, "Find As You Type" was executed and focus
skipped to "q" in other LINK.
If "F3", "Find next" was executed.
If "Tab/Shift+Tab", focus moved to next LINK.
(2) Test in DIV2 (stopPropagation is issued) :
When stopPropagation() was issued, onKepress event handler wasn't
scheduled.
"Find As You Type" was executed.
If "F3", "Find next" was executed.
If "Tab/Shift+Tab", focus moved to next LINK.
(3) Test in DIV3 (preventDefault is issued) :
When preventDefault(), onKeypress event handler was scheduled.
"Find As You Type" was not executed.
If "F3", "Find next" wasn't executed.
If "Tab/Shift+Tab", focus didn't move.
I guess ;
- "Tab", "Shift/Tab" is defined as "Deafult Action".
"F3"(Find again) is defined as "Deafult Action" too.
"Find As You Type" is defined as "Deafult Action" too.
- "Find As You Type" hooks keypress event at early stage of event model.
- Hooks keypress event in Capture Phase before any HTML element's event
listner captures the keypress event.
Then stopPropagation() by HTML element's event listner has no effect.
- Since "F3" key is defined as "Find next", "F3" key's action was executed
after stopPropagation() in reporter's test.
I think it is design of "Find As You Type", and preventDefault() is required in
this case.
Comment 10•20 years ago
|
||
Another observation on "return flase by OnKeypress event handler" and
"stopPropagation()" case.
(1) When OnKepress event handler returns false, "default action" is canceled.
(2) When stopPropagation() is issued in Capture phase,
target element's OnKeypress event handler is not invoked.
(3) Then "default action of the key", "Find next" when "F3", is normally executed,
even if user's OnKeypress event handler's logic has "return false;",
if stopPropagation() is issued by other event listner in Capture phase.
Updated•17 years ago
|
Assignee: events → nobody
QA Contact: ian → events
Comment 11•7 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046
Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.
If you have questions, please contact :mdaly.
Priority: -- → P5
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•