Closed Bug 286613 Opened 20 years ago Closed 20 years ago

body.onBlur not firing for text elements

Categories

(Core :: DOM: Events, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 230356

People

(Reporter: danswer, Unassigned)

Details

Attachments

(1 file)

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