[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]