[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 65606] handling of target "_new" in window.open
From:       Thomas Friedrichsmeier <thomas.friedrichsmeier () ruhr-uni-bochum ! de>
Date:       2003-11-09 14:36:10
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
     
http://bugs.kde.org/show_bug.cgi?id=65606     




------- Additional Comments From thomas.friedrichsmeier@ruhr-uni-bochum.de  2003-11-09 15:36 -------
This comment may not be very helpful at all, since it's mostly a blind guess at how konqueror works \
internally. Anyway, since you write, you doubt it's JS related, here's my guess at what might be the \
cause of the problem:

1. konqueror will most likely keep some internal list of named windows/frames. 
2. If you follow a link with a named target, konqueror will check, whether a window/frame by that name \
already exists. If the target exists, it will open the link there. 3. If it does not exist, it will \
create a new window and 3.b assign it the given target-name.
"_blank" and "_new" should be exeptions to rule 3.b. I.e. here, new windows should be created but they \
should _not_ be named. What seems to happen, is that using JS window.open, "_new" is not handled as an \
exception to 3.b, but rather just like any other target-name. Since at first no target named "_new" \
exists, konqueror will create a new window. However, it seems to assign the name "_new" to that window \
instead of leaving the window unnamed. On subsequently encountered links with target "_new", konqueror \
will see, that a window by that name exists and following rule 2 open the link there. Here, the symptom \
occurs regardless, whether this link is JS or non-JS. However the suspected cause, i.e. the generation of \
a window _named_ "_new" seems to be JS-related.


[prev in list] [next in list] [prev in thread] [next in thread]