Version: (using KDE KDE 3.2.0) Installed from: Compiled From Sources Compiler: GCC 3.3.2 OS: Linux If I choose: "Open links in new tab instead of in new window" then pop-up windows open in a new tab instead of a new window. It didn't work that way in 3.1.5. Example: http://www.indylighting.com/IndyLightingLive/featprodpg2/default.asp?content=485R.asp&pdfFilename=485R.pdf Now click on the link: 485R This is a pop-up but it opens as a new tab. If this was an intentional change, then this is a Wish List item that it needs to be configurable. But, I think that it is a bug since it is very inconvenient. -- JRT
*** This bug has been marked as a duplicate of 73361 ***
Well, How is this a bug? If the user chose to open links in new tabs, it is likely that she wants link to be opened in new tabs. Even the annoying popups.
I am reopening this bug because it now appears that Stephan Binner was in error when he marked this as a duplicate of bug 73361. -- JRT
Re: Comment #2: This is not about "annoying popups"; it is about pop-ups which are opened at the direct request of the user. -- JRT
Additional test case as posted on 'kde-devel': http://www.totallybamboo.com/tbwebstore/category.cfm?category=13 Now, click on the image above: "Windy Bamboo - $100.00". In Konqueror this opens a new tab instead of the small pop-up window that opens in both Mozilla browsers. This is the specific behavior difference -- this is the problem with Konqueror. But, it is more than just that -- the reason that I consider it to be a bug. Even if this behavior is what is wanted, it doesn't work correctly. After you click in Konqueror, this new tab is still tied to the tab that opened it. So, go to the new tab and open another web page in it. Now go back to the first tab and click the picture again. Nothing happens!! However, if you manage to open something else in the pop-up window on the two Mozilla browsers (which isn't easy) and go back and click on the image again, a new pop-up window will open. -- JRT
I think the behavior you describe in Comment #5 is correct in Konqueror and wrong in Mozilla: the reference is per the frame name - browsing to another URL will not change the frame name, so calling that name again should cause the original popup to be called. Konqueror has it right this time, the Mozilla behavior of changing the frame name when a popup is being browsed to a new URL may be convinient to some people (no one comes to mind at the moment), but it is not correct. Taking everything mozilla does to be the "right thing" as a rule of thumb is not a good idea. Besides, taking control of a chromless popup window is much easier in konqueror then it is in mozilla - just right click anywhere and pick "show menu bar" and from there its a snap. this is a Good Thing(tm).
Re comment #6: I believe that the important point is that in the test case: "nothing happens". I believe that that is a 'wrong thing'. Konqueror does not need to do the same thing as Mozilla -- there are probably other actions which would also be a "right thing". But, doing nothing when you click for a pop-up has to be considered to be a 'wrong thing'. -- JRT
The problem with the second click not doing anything is not a problem with konqueror's popup window behavior. its a javascript problem which I've yet to nail down - it occours even if you skip the complicated setup and just click on the image once and then a second time. The code for that site is terrible - specifically it calls makePopUpWin() to open a popup with the picture (using eval no less), and then doesn't put anything in that popup. another function - update() - that looks like its supposed to put the content in the popup never gets called. there are also more then a dozen other javascript errors, mistakes and just plain bad coding in that site - but nothing I wouldn't have expected from cold fusion coders. I have no idea why this code works in mozilla and not in konqueror, except that it does work in konqueror if I set the browser identification to mozilla. as I haven't been able to trace the javascript there (not using Konqueror's debugger, nor Mozilla's) I have to conclude there is some nasty server side detection script on that site that hates konqueror for some reason. As such I came to two conclusions: a) the problem with the test case in comment #5 has nothing to do with the description of the bug - I suggest you open another bug for that. b) The problems in that web site to numerous to trace and unless someone can provide a real minimal test case for the problem in comment #5 I won't invest any more time in it, simply because I don't care much for that site. When I say a real test case, I don't mean a URL - get the HTML from that site and trim it down until there's nothing left but the actual code that produces the problematic behavior. that's a few hours work - if you care to invest that much time in helping trace down the problem, then I'm sure other people will also find the time to fix it.
Well - I can't resist a good conundrum ;-) I've create a minimal test case for the problem you describe in Comment #5 and submitted it as a new bug #75426. I don't know if the developers would like to fix it as its also a policy issue and not only a coding issue, but I hope this summarizes the problem discussed. Except for that, this bug is a duplicate of Bug 73361 and I suggest to close it as such.
Re Comment #8 OK, I tried other sites and they don't have the problem "second click" problem so I accept your judgment that it is bad JavaScript specific to that site. -- JRT
*** Bug 73361 has been marked as a duplicate of this bug. ***
Re: comment #9 Thanks for filling the new bug. Since this bug has two test cases here, bug 73361 was originally a WishList item and Binner claims to have fixed it. It appears that it is best to close it as the duplicate. -- JRT
Re comment #8: Since it has been established that the JavaScript for the site in comment #5 is defective, I am adding a replacement test case which does not have the "second click" problem to have a clean test case: Under: Settings -> Configure Konqueror : Web Behavior Check the: "Open links in new tab instead of in new window" box. Go to: http://www.neimanmarcus.com:80/store/catalog/prod.jhtml?itemId=prod10350121&parentId=cat000532&masterId=cat000526&grandMasterId=cat000470&index=2&cmCat= Click on the "CLICK FOR LARGER VIEW" button and Konqueror opens a new tab instead of a pop-up window. This is the only issue that this bug should cover. (Please) :-) If you have another issue, please start a new bug. Additional comment: It appears that in this case, you can click either the LMB (button 1) or the CMB (button 3) and the same thing happens. Therefore, it would appear to me that one possible solution would be for the LMB to open it in a pop-up and the CMB to open it in a new tab. Comments on this should be directed to: kde-usability@kde.org -- JRT
Title changed to better reflect the specific issue. -- JRT
Why is this marked as a major bug ?? Why is this even being reported as a bug ?? Regarding comment#5, a pop-up window is also tied to the original window it is opened from. If you view another URL in the popup window and go back to the the original window and click on the popup url, what do you think happens ? The same window is reused. Why then should the behavior be different just because the popup url is shown in a tab ?
Re: comment #15: In regard to comment #5: Please see comments #8 & #9. This behavior is a JavaScript issue and is now bug #75426. Because that test case had JavaScript issues, a new test case was added in comment #8. This is a bug because there is an anomalous behavior. Specifically, checking the box: "Open links in new tab instead of in new window" in the KCM widget also affects the behavior of a LMB click on a link for a user activated pop-up. This configure option should only affect the behavior of a MMB click. It is major bug because it is a regression in mature code. As correctly stated by someone else on 'kde-devel', regressions should be considered more serious because they have a greater effect on the user -- something that previously worked stops working when the user upgrades. -- JRT
Comments from 'kde-usability': I have not proposed complicated behavior. The current behavior with the box checked: If you click on a (regular) link with button 1 (LMB) it opens the link in the current tab. If you click on a link with button 3 (MMB) it opens the link in a new tab. HOWEVER, if the link is a user activated pop-up, clicking on it with either button 1 (LMB) or button 3 (MMB) BOTH result in it opening in a new tab. My proposal: If the link is a user activated pop-up, clicking on it with button 1 (LMB) will (NEW or return to 3.1.5) open the pop-up in a pop-up window and that clicking on it with button 3 (MMB) will (UNCHANGED 3.2) open it in a new tab. This appears to be logically consistent with other behavior and will not require a new configuration option. -- JRT
Having reviewed part of the code: As Binner correctly stated, this problem occurs at line 1041 in: "kdebase/konqueror/konq_mainwindow.cc": if ( config->readBoolEntry( "MMBOpensTab", false ) ) { To work correctly, this condition needs to be && with 'was it a MMB click that caused this'. Until that can be added, I suggest that this line be changed to: if ( config->readBoolEntry( "MMBOpensTab", false ) && false ) { in the KDE_3_2_BRANCH to restore the behavior in 3.1.5. The addition: '&& false' needs to be replaced by something like: '&& isMMBClick' where 'isMMBClick' is Type bool. I attach a patch. -- JRT
Created attachment 4840 [details] Patch to restore 3.1.5 behavior Temporary patch to restore 3.1.5 behavior to the 3.2 BRANCH. See comment #18 -- JRT
I still wonder who gave you the right to mess with bug reports (wrongly closing #73361, wrongly messing with severities, moving to wrong categories) but I know who is about to revoke it. And now you propose a patch for Konqueror, after you moved the report to khtml which, which modifies the proposed patch of #73361 to just contain a false within an "if" while removing a configuration entry to choose between the two behaviors completely. Also hinding an "false" to disable the code there without any comment/reference why, convinces me what a "professional engineer" you're. ;-( > This is a bug because there is an anomalous behavior. That's only your expectation/interpretation. The checkbox text doesn't say anything that it only effects the middle mouse button. Neither does the WhatsThis text which mentions middle mouse button only as one case where a new window will be opened.
Re: comment #20 This is simple. This new "feature" doesn't yet work correctly. Therefore, it should be disabled in the release until it is fixed. -- JRT
HEAD has a GUI option to restore KDE 3.1 behavior.
Re: Comment #22 As Binner pointed out on bug 73361, just adding an option to restore the KDE-3.1 behavior does not fix the bug. The, so called, 3.2.x behavior is still not correct. To actually fix the bug, when using tabs, KHTML needs to be able to tell if the link is being opened with button 1 or button 3. It should open in a new window on button 1 and in a new tab on button 3. No additional configuration would be needed. Therefore, this bug has not been fixed. But, this now appears to be a request for a new feature so it is a WishList item. -- JRT
I agree with JRT although his patch certainly wasn't useful. The proposal in comment #17 is dead on. The problem with opening user-requested popups in a new tab is that firstly, the tab will open in the background (if the appropriate setting is set) and you have to click on it to see the popup which is a useless extra click. Also, most pages that are designed for a popup expect a certain size so they will look really bad in a new tab because they are statically coded for a certain WxH size.