Version: (using KDE KDE 3.1.4) Installed from: Debian testing/unstable Packages First of, not sure this is a bug according to the specs (which I was unable to find a definite source for), but it surely took me by surprise, so I expect it may be a common trap. Consider the following html-code: <html> <body> <a href="javascript:" onClick="window.open ('test.html', '_new', 'height=400,width=400,resizeable=yes,scrollbars=yes,'); return false;">This should open in a new window (javascript)</a><br> <a href="test.html" target="_new">This should open in a new window (plain html)</a> </body> </html> (to be saved in a file called "test.html", i.e. opening itself). Now, when clicking the non-javascript link will open a new window with the same file. Clicking the link in the new window will open yet another window. In constrast, clicking on the javascript-link will open a new window. However, clicking on either of the links in the newly openened window will _not_ open in a new window. Obviously the target-name "_new" was taken as a regular window-name, instead of synonymous to "_blank". What's worst about this, is that we now have a window called "_new" and all (javascript- _and_ html-) links specifying target="_new" will open in that window, i.e. the special meaning of target="_new" is lost. I gather that according to the specs (which I could not find), "_new" does not have a special meaning in window.open (), but you should use "_blank" instead. However, I would argue, that it probably does a lot more good than harm to treat "_new" the same as "_blank" in window.open () (Mozilla seems to do this). Even if you disagree here, however, I think, the target="_new" in plain html links should not loose it's special meaning in the case described above.
With Mozilla I can't open a 3rd window by clicking on the JavaScript link either. As the non-JS link works a second time in Mozilla but not in Konqueror there is ineed a difference in behaviour but I have my doubts that it is JS related.
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.
relating to target="..." in <a> tag This bug is still in KDE CVS>=20040112 (compiled from source) if you specify target="new" or "_new" konqueror will spawn two tabs or two windows.
Still present in 3.2.2
Created attachment 6451 [details] Target test cases
Hi, This bug is wrong but a part of it is right. I will explain this :) First of all "_new" is not a valid target name. "_blank" is the only valid one for opening a new window each time you click on a link. Konqueror will ignore this target name regarding http://www.w3.org/TR/REC-html40/types.html#h-6.16 This bug is not a Ecma related one. Simple links with target also have bugs. So will i create a new bug report for the real khtml bugs ? Here is the testcase http://shift.free.fr/trash/bugs/konqui/target.html * Konqueror fail on the target="foobar". It doesn't use the same window when clicking the seconf time on the link. * Konqueror fail on target="_foobar". It will ignore the target. Same bug for Mozilla and Opera. Franck P.S. : I sent my testcase in attachement too
> This bug is wrong but a part of it is right. I will explain this :) This is right, but a part of this is wrong ;-) Three points: 1) On target "_new" You'll note, that in the origingal report I was not sure, whether "_new" was a legal target-name. I know by now that it is not. However, a quick search on google will show you that I am not the only one confused about this: http://www.google.com/search?hl=de&ie=ISO-8859-1&q=target%3D%22_new%22&btnG=Suche&lr= Actually, in my personal opinion, this is good enough a reason to bend the standards a bit and treat "_new" just like "_blank". After all, few web-developers will chose target="_new" when they actually don't want a new window. I.e. the harm done if konqueror would bend the standards here is very little, while there is a non-zero cost to strict interpretation of the standards. Well, this is my personal opinion, and if others think, konqueror should be strict on all standards, I can see the merit of that, too. 2) Illegal target names like "_foobar" or "1thing" The standard says, those should be ignored entirely, konqueror (now) treats them just like any legal non-special target-name. Personally, once again, I think this behavior is reasonable. I can see no merit in adhering to the standard, which in this case would - as far as I understand it - ask to open the link-target in the current frame/window. Once again, that's just my opinion. 3) The original bug report ... ... was about an inconsistent handling of link-targets with plain HTML vs. JavaScript. that issue seems to be resolved as of konqueror 3.3. The testcase from comment #6 seems to work fine as well (except for issues 1) and 2)). So actually this bug could/should be closed. I'm not closing it myself right now, in case you think 1) or 2) are still an issue to be dealt with.
I agree with the analysis in the previous comment; no reason to treat _new in a special way if no other browser does it, and no reason to treat it as invalid either - unless someone can prove that some real-world web page relies on it.