Closed
Bug 286613
Opened 20 years ago
Closed 20 years ago
body.onBlur not firing for text elements
Categories
(Core :: DOM: Events, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 230356
People
(Reporter: danswer, Unassigned)
Details
Attachments
(1 file)
(deleted),
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
I would expect a vanilla page to expose every focus change to the document. But
the page below shows that this is not what happens with text elements.
The page below displays several control elements (checkbox, radio/option
buttons, text, textarea, select, link, and buttons) and the idea is to select
various ones by tabbing, the mouse, shortcut key, or any other way, and to see
whether it is possible to determine the item losing focus and the item that
intends to gain focus.
To do this, I put an onBlur in the body tag and show the .target,
.originalTarget (these 2 seem to be the 'from' element), and
.explicitOriginalTarget (seems to be the 'to' element).
Csaba Gabor from Vienna
<html><head><title>active element</title>
<script type='text/javascript'>
function elem(id) {return document.getElementById(id);}
function clearClick() { for (var idx in {oldie:0, oldie2:1, newie:2})
elem(idx).innerHTML = " "; }
function amendVal(id, evt, att) {
if (arguments.length<3) var newVal = evt; else // can pass in text as 2nd arg
var newVal = evt[att].name ? evt[att].name : (evt[att].nodeName ?
evt[att].nodeName : "not found");
var priorVal = elem(id).innerHTML;
var L1 = newVal.length; var L0 = priorVal.length;
elem(id).innerHTML = (L0<L1 || (priorVal.substr(L0-L1,L1)!=newVal))
// ? newVal : (priorVal + " *");
? priorVal + " >" + newVal : priorVal + " >" + newVal;
}
function fdFocus(evt) {
amendVal ('oldie', evt, 'target');
amendVal ('oldie2', evt, 'originalTarget');
amendVal ('newie', evt, 'explicitOriginalTarget');
}
</script>
</head>
<body onblur="fdFocus(event)">
This shows the results of the body.onBlur handler
<form name=myform action=''>
<button type=button name=button accessKey='B'><u>B</u>utton</button>
<input type=text name=textbox>
<input type=text name=bluebox style="border:solid 1px blue">
<input type=radio name="option">
<input type=checkbox name=checkBox>
<textarea name=textarea>Some initial text</textarea>
<button type=button name="clear button" accessKey='C'
onClick="clearClick()"><u>C</u>lear</button>
<a name=link href="http://google.com" onclick="return false">Sample link</a>
<select name=select><option>foo</option></select>
</form>
<table><tr><td>target:</td><td id=oldie> </td></tr>
<tr><td>originalTarget:</td><td id=oldie2> </td></tr>
<tr><td>explicitOriginalTarget:</td><td id=newie> </td></tr></table>
</body></html>
Reproducible: Always
Steps to Reproduce:
Tab or click between the various controls.
Actual Results:
1. The onBlur does not fire when the control being left is a text/textarea control.
2. It fires three times when selecting from a (firing) control to the address
bar or the google bar, or when Alt+Tabbing to a new app.
3. If the focus is on the Clear button and I select the textarea then
explicitOriginalTarget shows textarea when I do it with shift+tab vs. clear
button when I do it with the mouse.
4. If the focus is on the 1st Button (by alt+b) and then I do shift+tab then
explicitOriginalTarget shows button
5. If focus is on the Clear button and I press alt+b to get to the 1st Button,
all three targets show button vs if I click the 1st Button with the mouse, then
.target and .originalTarget show 'clear button' as expected.
6. Put the focus on the select element (ex. alt+c, tab, tab). If you now do
one more tab to get the focus to the address bar vs. clicking in the address bar
you get two different version (of 3 events): keyboard => .target,
.originalTarget of last 2 events are #document, otherwise all are 'select'.
Mouse => 1st event all 'select's, the last two are all #document.
7. Just to lighten things up a bit, press alt+c (clears the entries, focus goes
to the Clear button). Now click the 1st Button. Now press Shift+Tab. Tada,
you're back at the clear button. (if you press alt+c, alt+b, then do shift+tab
you get expected behaviour).
Expected Results:
1. I expect the text type of elements to behave like the other ones in this
regard. Let grandpappy know you're leaving and let him know where you're going.
2. Firing so many times seems like overkill.
3. I expect navigating with the keyboard (shift+tab) to not lose the
destination information (.explicitOriginalTarget). The mouse had the right
behaviour.
4. I expected .explicitOriginalTarget to show me #document
5. I expect navigating with the keyboard (alt+b) to not lose the source
information (.target, .originalTarget). The mouse had the right behaviour.
6. I don't like either behaviour because by the time the
.target/.originalTarget should be 'select' to indicate the element losing focus,
and then .explicitOriginalTarget could be #document. And once would be fine by me.
7. Oops, looks like someone's confused. Shift+Tab should not select the Clear
button.
All this is motivated, once again, by the search for document.activeElement
This time my idea was to have a dummy control equipped with .onDOMActivate (a la
IE's onBeforeActivate), set focus to that control and see where the focus came
from, and then return false to prevent the focus being transferred.
Unfortunately, it looks the the implementation described in bug 60212 was backed
out, or didn't make it to Firefox 1.0.1
Undaunted, I figured I'd roll my own by hanging an .onBlur (or .onFocus) on the
document which I figured would get information about all the coming and goings
of its descendants. And that's how I came across these issues.
Notes to self: related seem to be: bug 4033 (file input element), bug 103110
(sample code), and bug 194646 (initUIEvent)
Reporter | ||
Comment 1•20 years ago
|
||
Oops, the expected behaviour on #3 is backwards. The keyboard behaviour
(Shift+tab from the Clear button) is the keeper since it's the mouse behaviour
that throws away the destination (.explicitOriginalTarget) textarea.
Comment 2•20 years ago
|
||
Actually, per DOM spec our behavior is correct (and all other elements should
behave like text inputs).
*** This bug has been marked as a duplicate of 230356 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•