|Property/method value type:||Boolean primitive|
|Supported by objects:||A, Anchor, APPLET, AREA, BUTTON, CAPTION, Checkbox, DIV, Embed, FIELDSET, FileUpload, IMG, Input, Layer, LEGEND, MARQUEE, OBJECT, Password, RadioButton, ResetButton, SubmitButton, TABLE, TEXTAREA, TextCell, Url|
|Argument list:||aHandler||A reference to a function object to handle the event|
When the input focus is directed onto a control, the browser will generally highlight the item to indicate that the cursor is localized there and that any keyboard input will affect that <INPUT> item.
DOM level 2 refers to this as a DOMFocusIn event, which employs event bubbling for its propagation and cannot be canceled.
In MSIE, you can hide the visible effect of an object acquiring focus by means of the hideFocus property on HTML elements.
It is somewhat easy to create an onBlur/onFocus recursion, which leads to an endless loop with objects exchanging focus backwards and forwards. Focus on object A triggers a blur event on object B, which tries to wrest back the focus again because it believes its content is incomplete. Meanwhile object A isn't happy with its content either and so they play 'Tug-of-War' with one another. This continues until the browser has a race hazard attack and GPFs - that is, if it hasn't already fallen over due to a stack overflow. If you're lucky, only the browser will crash, but it could bring down the OS as well.