Closed Bug 286613 Opened 19 years ago Closed 19 years ago

body.onBlur not firing for text elements

Categories

(Core :: DOM: Events, defect)

Product:
Core
Component:
DOM: Events
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 230356

People

(Reporter: danswer, Unassigned)

Details

Attachments

(1 file)

An updated version of the code found in the original report
3.16 KB, 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 = "&nbsp;"; }
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>&nbsp;</td></tr>
<tr><td>originalTarget:</td><td id=oldie2>&nbsp;</td></tr>
<tr><td>explicitOriginalTarget:</td><td id=newie>&nbsp;</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)
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.
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: 19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: