I think we should change the behaviour, if it still exists.

From the Netscape Documentation Server:


Description
Use the focus method to navigate to a specific form element, window, or frame,
and give it focus. You can then either programmatically enter a value in the
form element or let the user enter a value. Giving focus to a window brings the
window forward in most windowing systems.

    Note 

    On some platforms, the focus method gives focus to a frame but the focus is
not visually apparent (for example, the frame's border is not darkened). Please
see the release notes (after starting Netscape, choose Release Notes from the
Help menu). 

This bug is still present in KDE HEAD from CVS on Sun Sep 22 16:17:14 EDT 2002 
(which means still present in KDE 3.1Beta). 

Subject: patch: make window.focus() raise the window

Hi,

According the Netscape docu window.focus() should not only set the
keyboard focus on the specified window but it should also bring it
to the foreground (make it visible) . The attached simple patch does
the trick (see also http://bugs.kde.org/show_bug.cgi?id=31916) .

Ok to commit?

Simon


Created an attachment (id=66)
kjs_patch.txt

*** Bug 36652 has been marked as a duplicate of this bug. ***

try 
http://wetter.orf.at/stm/main 
 
and click on the different villages - a popup with details opens 
click the next village - the former popup reloads with the new date, but stays in the 
background IMHO it should be displayed in foreground 
 

Created attachment 1411 [details]
patch for CVS-HEAD, please review

Subject: kdelibs/khtml/ecma

CVS commit by danimo: 

Patch by Ferdinand Gassauer: Properly support window.focus()

CCMAIL:31916-done@bugs.kde.org


  M +3 -1      kjs_window.cpp   1.334


--- kdelibs/khtml/ecma/kjs_window.cpp  #1.333:1.334
@@ -1268,6 +1268,8 @@ Value WindowFunc::tryCall(ExecState *exe
     KHTMLSettings::KJSWindowFocusPolicy policy =
                 part->settings()->windowFocusPolicy(part->url().host());
-    if(policy == KHTMLSettings::KJSWindowFocusAllow && widget)
+    if(policy == KHTMLSettings::KJSWindowFocusAllow && widget) {
+      widget->topLevelWidget()->raise();
       widget->setActiveWindow();
+        }
     return Undefined();
   }

*** Bug 57777 has been marked as a duplicate of this bug. ***

*** Bug 58587 has been marked as a duplicate of this bug. ***

Same problem has to be solved if pop up windows show up in tabs instead of 
windows. the tab shoud get the focus. 
cu 
ferdinand 

and get the active tab - displayed 

changed to major, because normal users expect, that a link (from kmail) opens in an window "on top"

Just reporting that the behaviour (focused tab doesn't get in the foreground) is still existing with konqueror 3.2.2 (gentoo ebuilds).

Regualar users?  Application pop-ups.

I think: follow the window manager rules for focus or stay off the desktop.

John: Please explain your comment in detail

CVS commit by waba: 

BUG: 31916
Let window.focus() activate tab


  M +2 -1      kjs_window.cpp   1.387


--- kdelibs/khtml/ecma/kjs_window.cpp  #1.386:1.387
@@ -1512,4 +1512,5 @@ Value WindowFunc::tryCall(ExecState *exe
       widget->topLevelWidget()->raise();
       widget->setActiveWindow();
+      emit part->browserExtension()->requestFocus(part);
         }
     return Undefined();

Here it "works" only if the tab is activated from another konqueror tab.

It does NOT work if  - for examply - the "bug report" is initialised from another app or a http-link is clicked in kmail.

konqueror stays in the background although the tab gets activated. IMHO not the desired behaviour as described above. one still has to click the taskbar to bring konqueror in the foreground.

cu ferdinand

Currently using CVS HEAD and both the konq window and tab get come to the foreground when a link in an external app is clicked (in this case KMail).

Is this now closeable?

Here it does NOT work if konqueror is already open and
"open as tab in existing konqueror when URL is called externally" is checked
cu
ferdinand

Whats your "focus stealing prevention measures" setting? I had it set to "none" - any other setting will stop konq coming to the foreground (although the taskbar item will flash).

Indeed if I change it from "low" to "none" it works for me.

IMHO this is not the desired behavior - If the user actively requests to open a window by clicking a link, the focus stealing prevention should not intercept this. To get the desired behavior this policy has to be turned off and hence is no used any more.

Although it doesn't fix this bug, this might get your system working how you want:

In Window specific settings (KControl->Desktop) you should be able to set a separate focus rule for konqueror.

Hi!
Thanks for the hint. 

I followed your suggestion and it works the way I think it should.

I found the following entry, which IMHO should be made standard as I feel "non expert" users are definitely not able to set up this behaveour. 

Or this matter should be assigned to the ked-usability group.

kwinrulesrc
[1]
clientmachine=linuxfg04
clientmachinematch=0
description=konqueror accept focus
fsplevel=0
fsplevelrule=2
title=Bug 31916 - window.focus() does not raise tab - Konqueror
titlematch=0
wmclass=Konqueror
wmclasscomplete=false
wmclassmatch=1

cu
ferdinand

I opened the original bug report, the issue was quit different. It was about pop-up windows and their focus. Now it's about which tab gets the focus.
Personally, I don't really have any idea of a perfect solution. IMHO popups should still be opened as popups unless forced (by reight-click or "open in Tab") otherwise. 
I don't have a suggestion about how to handle this. Don't ask me, I'm out.

whatever happens, if the user clicks on a link, the content should be displayed / opened in the appropriate application.

this bug is now really old (11 months no action)

in the meantime lots of kde versions came out

can we close this one? 

I tried the URL of comment #5 

http://wetter.orf.at/stm/main

which seems to work with konqueror 3.4.2.

This should be closed.

This is now officially a dead bug.
;)