Home Library Learn Downloads Support Community
Sign in | United States - English | |
6 out of 20 rated this helpful - Rate this topic

focus method

[This documentation is preliminary and is subject to change.]

Causes the element to receive the focus and executes the code specified by the onfocus event.

Document Object Model (DOM) Level 2 HTML Specification, Section 1.6.5

Syntax

object.focus()

Standards information

Parameters

This method has no parameters.

Return value

Type: HRESULT

If this method succeeds, it returns S_OK. Otherwise, it returns an HRESULT error code.

Type: HRESULT

If this method succeeds, it returns S_OK. Otherwise, it returns an HRESULT error code.

Remarks

This method raises the onfocus event. The effect depends on the object calling the method. When called for child windows (such as those created with the open method of a window object), focus brings the target window to the foreground.

Elements cannot receive focus until the document finishes loading.

Windows Internet Explorer 8 and later. The focus method no longer brings child windows (such as those created with the open method) to the foreground. Child windows now request focus from the user, usually by flashing the title bar. To directly bring the window to the foreground, add script to the child window that calls the focus method of its window object.

Windows Internet Explorer 7 and later. For security reasons, child windows will only respond to the focus method when the following conditions are true:

  • The child window does not have multiple tabs open.
  • The focus method was not triggered by a double-click action.

If any of these conditions are true, the child window ignores the focus event.

As of Microsoft Internet Explorer 5, elements that expose the focus method must have the TABINDEX attribute set.

 

 

Build date: 3/8/2012

Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ
Document finished loading?
The specification clearly states that "Elements cannot receive focus until the document finishes loading". What is the preferred way in IE to make sure that the document is finished loading?
History
Window.Focus issue
[It is unclear whether the following case was tested with TABINDEX set, as required. Ray.]

IE8 and later ..." add script to the child window that calls the focus method of its window object."

is there any way to bring a child window into the foreground in IE8 or later? the method suggested in the description above doesn't work. 

test code:

<html>
<head>

<script type="text/jscript">
var pwin = null;
var cwin = null;
var swin = null;

var count = 1;

//window.onfocus = bringToFront;
//window.onfocus = function() { window.focus(); return false; };
function bringToFront() {
try {
self.status = "try to bring self to front " + count;
//setTimeout("window.focus()", 1000);
//self.focus();
//self.blur();

window.focus();
//window.document.focus();
//document.getElementById("field").focus();
//window.moveBy(50, 50);
//window.focus();
//window.document.body.focus();

//self.document.body.fireEvent("onfocus");
count++;
} catch (e) {
alert(e.message);
}
return false;
}

function spawnWindow() {
cwin = window.open("test_IE8MultiWindow.htm");
cwin.count++;
return cwin;
}

function spawnSibling() {
if (opener != null)
swin = opener.spawnWindow();
}

function focusChild() {
if (cwin != null) {
cwin.focus();
}
return false;
}

function focusSibling() {
if (swin != null) {
swin.focus();
}
return false;
}

function focusOpener() {
if (opener != null) {
opener.focus();
}
return false;
}
</script>

<style type="text/css">
#field
{
width: 35px;
}
</style>
</head>
<body>
<input id="field" value="1" />

<script language="jscript" type="text/jscript">
if (opener != null && opener != window)
document.getElementById("field").value = new Number(opener.document.getElementById("field").value) + 1;

</script>
<input type="submit" onclick="spawnWindow()" value="Spawn Child" />
<input type="button" onclick="spawnSibling()" value="Spawn Sibling" />
<br />
<input type="button" onclick="opener.bringToFront();" value="opener bringToFront" />
<input type="button" onclick="focusOpener()" value="focus Opener" />
<input type="button" onclick="focusChild()" value="focus Child" />
<input type="button" onclick="focusSibling()" value="focus Sibling" />
</body>
</html>

History
Remarks, Conflicts - scroll-position, override
CAUTION #1. This method resets scroll-position and scroll-variables variously to--

Choice A. Top-Left, to show the cursor blinking at the Left of the Top text [non-absolute-position text];
Choice B. Top-Right, to show the Top-edge (scrollTop=0) and the Right-edge (scrollLeft=maximum);

N.B. #1. Choice A. declares the same scroll-variables as Choice B., just not the same scroll-position.

N.B. #2. This method results in the scroll-position jumping erratically while clicking or grabbing the scrollbar ... until the selected text reappears, or the scroll-variables are set. (Test case CONTENTEDITABLE)

REMEDY: Grab the scroll-variables before using textrange.select() or focus() -and- yank the scroll-variables afterward to their saved values.
__

CAUTION #2. If called from an element event handler (Test case onmousedown) with UNSELECTABLE=true, this method cannot pull focus from the in-chrome Location bar to another element, (yet it can pull focus from the Find Dialog box and other selectable elements).
__

N.B. #3. Despite focus, The in-chrome Find Dialog loses contact with reality upon reloading oContent from localStorage.
History
Window.focus() works fine on IE8
When I am uisng IE8 8.0.6001.18702IC version on XP version 2002 SP3. Window.focus() working fine and brings my child window to foreground. No need to write extra line of code on child window to bring it to foreground.

However when I tested the same on vista business SP1 32 bit and IE8 8.0.6001.18813. It behaves as mentioned in the post.
History
input type=text / zIndex bug
If you transfer the focus to an input control and then you stack another element on the top of the input control, the caret apears as if it belonged to the second element and not to the input control, even if the second element has a higher zIndex. In an old fashioned web aplication you want the space used by the input control to be clear all the time, however moden needs requiere windowing systems that eventualy and unavoidably will place something above an input control. Every time I'm more and more disapointed of Microsoft because it seems like everyone else was able to forseen this kind of scenarios long time ago and Microsoft hasn't.
History