I can\'t seem to get this to work.
In response to a click, window A opens window B (which then has focus). Then, in response to a click on B, the window calls
Workaround In main window added script function:
function here() {
alert('Welcome Back') // seems needed to wake up document
window.focus()
}
In opened window invoke script function:
function HomeTab() {
O = window.opener;
if (O)
if (O.closed) alert('Home page has been closed')
else O.here()
else alert('This tab has no home page')
}
Works widely differently in different browsers Some will have the parent tab blink Some mark the parent tab, and you have to notice it Some you have to click on home tab the first time and you can then give it permission to go directly to home tab without a confirm box.
I can see why a browser/OS will not allow a child windows to take over the focus (abuse of power). Here is a workaround:
JS Parent:
var child = window.open('child.html', 'child');
window.external.comeback = function() {
var back = confirm('Are you sure you want to comback?');
if(back) {
child.close();
} else {
child.focus();
}
}
JS Child:
// assuming you have jQuery
$('.btn').click() {
window.opener.external.comeback();
};
--I am using this code in a real world application to handle a checkout request that runs in child window, and I need to gracefully return to the parent window.
See: SimplifySites.com
Web-facing or private intranet?
Window management is up to the Browser and the OS. HTML & ECMAscript have nothing to say about it.
If this is for a public-facing website, then just don't bother -- as they say, "Don't break the web."
But I really wanna!
If this is for some tightly managed (say Intranet) application of some kind then you'll need to resort to writing Addons/Extensions. It's certaintly easier if you can restrict yourself to a single browser & platform.
EDIT: Example for Firefox on Win32...
This solution works as a custom addon for Firefox which uses jsctypes
internally to load a Win32 DLL. The window_focus()
JavaScript function is exposed which does what you want.
There are 3 parts to this solution:
I built a simple GUI DLL project in MSVC++ with the later two files & compiled wmctrl.dll
, depending on msvcr100.dll
, and used Dependency Walker to find the "plain C" symbols exported by the DLL for use by js-ctypes. E.g: ?wmctrl_find_window@@YAKPAD@Z
is the "plain C" symbol for the C++ api function called wmctrl_find_window
.
As a caveat, this code relies on temporarily being able to change the title of the window that needs to be focused so that Win32 APIs can examine all windows on your desktop to find the correct Firefox window.
You need to have access to privileged Mozilla platform APIs, i.e: JavaScript inside a Firefox Addon.
In your privileged JavaScript code:
// get API constants (might already be available)
const {Cc,Ci,Cu} = require("chrome");
// import js-ctypes
var file=null, lib=null, ctypes = {};
Cu.import("resource://gre/modules/ctypes.jsm", ctypes);
var ctypes = ctypes.ctypes;
// build platform specific library path
var filename = ctypes.libraryName("wmctrl"); // automatically adds '.dll'
var comp = "@mozilla.org/file/directory_service;1";
var file = Cc[comp].getService(Ci.nsIProperties).get("CurProcD", Ci.nsIFile);
file.append("browser_code"); // or whereever you put your DLL
file.append(filename);
// get the JavaScript library interface (load the library)
var lib = ctypes.open(file.path);
// wmctrl_find_window: returing unsigned 32bit (long) "window handle"
// takes string "window title".
var find_window = lib.declare(
"?wmctrl_find_window@@YAKPAD@Z", /* plain "C" DLL symbol */
ctypes.stdcall_abi, ctypes.uint32_t, /* return type: uint32 */
ctypes.char.ptr); /* parameter: string */
// wmctrl_window_focus: takes unsigned 32bit (long) "window handle".
var window_focus = lib.declare(
"?wmctrl_window_focus@@YAXK@Z", /* plain "C" DLL symbol */
ctypes.stdcall_abi, ctypes.void_t, /* return type: void */
ctypes.uint32_t); /* parameter: uint32 */
wmctrldll.h
#ifdef WMCTRLDLL_EXPORTS
#define WMCTRLDLL_API __declspec(dllexport)
#else
#define WMCTRLDLL_API __declspec(dllimport)
#endif
WMCTRLDLL_API void wmctrl_window_focus (unsigned long wid);
WMCTRLDLL_API unsigned long wmctrl_find_window(char* find_title);
wmctrldll.cpp
typedef struct {
HWND hWnd;
char title[255];
} myWinSpec;
BOOL CALLBACK EnumWindowsProc(HWND hWnd, LPARAM lParam) {
char String[255];
myWinSpec* to_find = (myWinSpec*) lParam;
// not a window
if (!hWnd) return TRUE;
// not visible
if (!IsWindowVisible(hWnd)) return TRUE;
// no window title
if (!GetWindowTextA(hWnd, (LPSTR)String, 255)) return TRUE;
// no title match
if (strcmp(String, to_find->title) != 0) return TRUE;
to_find->hWnd = hWnd;
return FALSE;
}
WMCTRLDLL_API void wmctrl_window_focus(unsigned long wid) {
SetForegroundWindow((HWND) wid);
}
WMCTRLDLL_API unsigned long wmctrl_find_window(char* find_title) {
myWinSpec to_find;
sprintf_s(to_find.title, sizeof(to_find.title), "%s", find_title);
to_find.hWnd = 0;
EnumWindows(EnumWindowsProc, (LPARAM)&to_find);
return (unsigned long) to_find.hWnd;
}
From the fine manual:
Makes a request to bring the window to the front. It may fail due to user settings and the window isn't guaranteed to be frontmost before this method returns.
Emphasis mine. Calling focus()
is just a request and the browser is free to ignore you and you should generally expect to be ignored. Consider what sorts of nefarious things you could get up to by switching focus to a tiny window while someone is typing if you need some reasons why a browser would ignore your request.
If you need focus()
to work for your application to work then you need to redesign your application so that it doesn't need to call focus()
.