Version: (using KDE Devel) Installed from: Compiled sources OS: Linux I have set in "Web Behavior" > "Open links in new tab instead of in new window" I use Horde/Imp webmail application when I click compose (it uses javascript to open new window) konqueror put this window to new tab instead opening new window. I think this is the "proper" way and mozilla works like this. So, konqueror should distinguish ordinary link and javascript open window.
Ok, mozilla doesn't work like this almost. It doesn't automatically open link to new tab. Instead there are config options: Open tabs instead of windows for - Middle-click, Ctrl+click or Ctrl+Enter on links in a Web page - Ctrl+Enter in location bar So maybe this kinda feature request.. be able to disable that automatic opening link in new tab.
*** Bug 73851 has been marked as a duplicate of this bug. ***
This is not a wishlist item; it is a bug. This works correctly in Mozilla. Please see example in Bug 73851 -- JRT
esp when javascript open window asks for no chrome AND specifies the exact size, a new window should be opened, not a new tab, imho.
I think anyone sites that asks for exact-size deserves to be broken. In fact, I don't see how opening a link in a tab breaks the site, it only follows user preferences about where to open links.
> I think anyone sites that asks for exact-size deserves to be broken. > In fact, I don't see how opening a link in a tab breaks the site, it only > follows user preferences about where to open links. If you use Horde/Imp webmail, it's really annoying when it open compose window to tab (and even worse when it open new windows in background, because you may not notice that windows is there in another tab and you still waiting the window to pop up), and second of all my wive really hate that :) It should be configurable..
Comment #5 1. This works correctly in Mozilla. 2. After it opens the popup in a new tab, it somethines gets confused. -- JRT
When you mess with the priority I assume it's you whose task it is.
*** Bug 74276 has been marked as a duplicate of this bug. ***
I'll second the switch back to 3.0.x behaviour. there are loads of sites where you dont want popups to disappear in a new tab. www.klack.de for one. Best, imho, would be a mozilla-like behaviour (configurable): middle mouse click on a link creates a new tab no matter what; regular click does what the website wants (new window or whatever).
I'm also in favour of giving back meaning to the mmb. From what I can see, I now have to decide on opening everything always in a new tab or new window in the config file. Before I could decide per every link I click, by clicking with lmb or mmb. Some sites do make sensible use of pop-up windows for "more info" or help type pages, and to have them come up as tabs is less useful. Or, and this is more work, make it possible to assign mouse buttons or mouse button/keyboard combos to shortcuts, and add "Open in new tab" as an action capable of having a shortcut assigned to it. I would love to see this make 3.2.1 Otherwise, great work, chaps!
I think the proper way to handle this would be as suggested in Bug 74276: - "open new windows in tab instead of window" causes only windows opened by <a target> and window.open() w/o the 'options' to be opened in new tabs. - add another option such as "open popup windows in tabs" to force window.open() calls with 'options' to open in a tab, otherwise they'll always open as new window. IIRC, the 3.1.4 behavior was that setting "new window in tabs" still had popup window open in new window. I think this is correct, as was mentioned in comment #11, some popups are of good use and acceptable, even if they specify size or "no chrome" or stuff like that: this mechanism wasn't invented solely for spamers and popup ads.
Re: comment #8 First the logic of your statement is questionable. Second, to start with this is a political question. I.E. (DH): It has not yet been establlished (at least I do NOT know) if this was an intentional change or if this was a coding error. Will someone that knows, please advise. -- JRT
James, why is the logic wrong? There is an unwritten law that you don't rule over the time of others or on what they have to work. Or to say it with http://bugs.kde.org/bug_status.html#priority: "This field is utilized by the programmers/engineers to prioritize their work to be done." If you change the priority it's valid to assume that you consider it your work - or it's simply arrogant as usual of you. The change in KDE 3.2 to open popups in new tabs is intentional, and it's exactly what the checkbox description reads. There is no distinction if that it's caused by a normal link or window.open, onLoad or onClick, left or middle mouse button, pop-up wanted-size or not.
IMHO this change is wrong (and apparently I'm not the only one who thinks so). at the least I want to be able to distinguish between links that I choose to open in a new tab (middle click) and links that the site wants to open.
Stephan Binner wrote: > ------- You are receiving this mail because: ------- You are the > assignee for the bug, or are watching the assignee. You are on the CC > list for the bug, or are watching someone who is. > > http://bugs.kde.org/show_bug.cgi?id=73361 > > > > > ------- Additional Comments From binner kde org 2004-02-15 23:21 > ------- James, why is the logic wrong? Because if it is only to prioritize your own work, there is no need to post it on BugZilla. You need only post it on your to do list. > There is an unwritten law that you don't rule over the time of others or > on what they have to work. Interesting rule. Unfortunately, another way to state that is that the KDE project will never have any quality control. > Or to say it with http://bugs.kde.org/bug_status.html#priority: "This > field is utilized by the programmers/engineers to prioritize their work > to be done." So, you quoted something that doesn't make sense. The fact that this appears to be an official position makes it all the more unfortunate. > If you change the priority it's valid to assume that you consider it > your work - or it's simply arrogant as usual of you. I realize that many developers don't want any QA, but I see it as the QA team's job to assign priorities. So, if you say "trying to do a good job" == "arrogant", you need to carefully reconsider your position. When, or if, this gets organized, I suggest that the priority should be controlled by the QA team, and if there is currently someone in charge that I need to answer to, I will do so. > The change in KDE 3.2 to open popups in new tabs is intentional, This is very unfortunate. Mozilla does not work that way. And there are a lot of users that feel that the Mozilla behavior is best. This change, like several others in KDE-3.2 appears to have been done with little consideration. And, yes, I realize that a lack of design consideration is part of your model of OSS development. > and it's exactly what the checkbox description reads. There is no > distinction if that it's caused by a normal link or window.open, onLoad > or onClick, left or middle mouse button, pop-up wanted-size or not. Well at least it is good that the checkbox description correctly describes the behavior. But, that has nothing to do with the fact that the behavior is WRONG. -- JRT
So we got two possible behaviors. 1. Open new windows in a new tab. 2. Use the middle mouse button to open windows in new tabs. IMO the 2nd one is much more useful than the first one. I want to use my middle mouse button to use windows in new tabs, and that's it. Opening every pop up window in a new tab can be very annoying. I'm voting for this. J.A.
Created attachment 4731 [details] See comment 18 I can also tell you what I can't bear: Surfing, opening links in background tabs and being cluttered with onload popups for a page I don't even look at. This doesn't happen anymore with the current implementation. This patch adds a hidden setting (add "PopupsWithinTabs=false" to "[FMSettings]" section of your ~/.kde/share/config/konquerorrc) to get back the KDE 3.1 behavior. Any other solution seems to require too much new code to distinguish more cases for a bugfix release or would lead to GUI changes/description inconsistency.
> I can also tell you what I can't bear: Surfing, opening links in background > tabs and being cluttered with onload popups for a page I don't even look > at. This doesn't happen anymore with the current implementation. > > This patch adds a hidden setting (add "PopupsWithinTabs=false" to > "[FMSettings]" section of your ~/.kde/share/config/konquerorrc) to get back > the KDE 3.1 behavior. Any other solution seems to require too much new code > to distinguish more cases for a bugfix release or would lead to GUI > changes/description inconsistency. All I ask for is for my middle mouse button to be binded to "open in new tab" instead of "open in new window" (and everything else working as usual). Like it works in mozilla and firefox. Wouldn't this solve all this problems? Why the need to test for cases? J.A.
This patch will apparently cause the behavior most people here will compromise on. will it be commited to CVS ? Just a note about the code - if I understand correctly, the patch applies to the part that deals with window.open() and <a target>, *not* to MMB clicks, and currently the behavior seems to be like this: "when window.open() or <a target> is called, open it in a new tab if MMB opens tabs", while after the patch the behavior would be: "when window.open() or <a target> is called, open it in a new tab if MMB opens tabs and the user has *not* specifically requested that popups will always open in a new window". This seems rather complicated to me. wouldn't it be better (disregarding the whole "to big of a change for a bug fix release" for a second here) to make the behavior - "when window.open() or <a target> is called, open it in a new tab if the user requested that popups will be opened in tabs ? i.e.: if ( config->readBoolEntry( "PopupsWithinTabs", false ) ) After all - once you have "PopupsWithinTabs", what does the MMB setting has to do with anything here ?
I am abandoning this bug since the proposed patch does not appear to fix the problem which I reported as Bug 73851. Bug 73851 will be reopened with an additional test case. -- JRT
Bug 73851 has two test cases and this was originally a WishList item. Binner claims to have fixed this bug. Therefore, I am closing this as a duplicate. I will add an additional test case to Bug 73851 since it has been pointed out that my second one is based on a site with bad JavaScript. Please direct further comments on the (original) limited and very specific issue in bug 73851 there. If you have other related issues, please open a new bug since the issue is getting a bit muddled in this one. -- JRT *** This bug has been marked as a duplicate of 73851 ***
> Binner claims to have fixed this bug. I did not. I attached a patch here which I not even committed. And I still consider this as a valid wish. > Therefore, I am closing this as a duplicate. You're not helpful. Don't forget to campaign now for votes for the other report. ;-(
@comment 19: Just make it work like Firefox" (left button same/new window, right button new tab) is not possible at the moment because khtml doesn't keep track of what mouse button caused a JavaScript action.
Re: last comment Then don't do that. I'm not even sure if firefox actually works that way (it doesn't as far as I remember). IMHO there are two distinct behaviors - user initiated popups (doesn't matter which button) and regular links. currently there is one setting that says "open new window in tabs" which controls both actions. I suggest that the least change with the most functionality is to make said setting cause only regular link clicks to open in new window - only for MMB clicks: khtml does know to distinguish between MMB and LMB clicks on normal links. The behavior for javascript/taget invoked new window is in different functions which should get a different setting - something like "open popups in tabs". That way you have the following behavior: a) LMB click on a link: browse in the current window - not configurable. b) MMB click on a link: open in a new window or tab - configurable. c) site requests a valid new window (target or window.open): open in a new window or tab - configurable. If you really want to go all out, add the mozilla extension that allows you to browse in the same window for case (c). I know that some people would really like it (my brother comes to mind), and I don't think it will be that difficult.
Just verified the Mozilla behavior: - regular link: it behaves as described (which is the same as in KDE 3.1.5). - window.open(): left click opens a window, MMB opens a new disfunctional tab (it actually opens a new tab with the href of the click which is either the javascript command which then doesn't work or its nothing because the link calls window.open using an onclick event) - link with target: works as descrined - LMB opens a new window, MMB opens a new tab. IIRC this is actually the same as the khtml behavior of 3.1.5.
Oded, what you say in comment 25 is fine for HEAD (leading to KDE 3.3 or 4.0) where the checkbox description and "What's This" text can be changed to reflect this behavior and where new config options can be added. We will then hopefully even have the possibility to differ LBM/MMB on "target" links (at latest in binary incompatible KDE4). But I guess what most here interest is short term and the KDE 3.2.x series. That's why I proposed the patch attached to this bug report to make it possible to choose between the old and current behavior. And it should have default "true" for "PopupsWithinTabs" (and for this reason the conjunction with the "MMBOpensTab" check) to match the current checkbox description. I don't know what the goals of James are with the patch attached to #73851 which forces his wanted behavior on every user.
I don't understand why should the current 3.2 behavior be the default and not the 3.1 behavior ? supposedly, if you want to minimize "user surprise" one would prefer to have the 3.1 as the default behavior so that users upgrading will not be surprised to find the functionality was changed on them. I don't agree with you that this is because of the configuration text and "What is" text. the text currently specificly mentiones links and does not say anything about popups. the way I see it is that the current GUI is misleading by saying that only links are affected by this and leaving the user to assume that popups behave normally (i.e. - as in any other browser in the world: opens in a new window). The best way will be to fix this w/o changing the texts - set the default behavior to open popups in a new window and have a hidden configuration option to allow popups to open in a tab.
Binner appears to have committed his patch. Two problems with it: I'm not sure about the name of his boolEntry string. The default is WRONG. The default should be false. -- JRT
I agree, the default should be PopupsWithinTabs=true, just as it was in KDE 3.1.5. Without searching the bugs/changelog, noone will know about this undocumented setting.
On Friday 27 February 2004 19:29, Fridtjof Busse wrote: > I agree, the default should be PopupsWithinTabs=true, just as it was in KDE > 3.1.5. I'm sorry, but the 3.1.5 behavior was that popups where in a new window (controlled by the javascript "window.open handling" configuration). when using tabs, only MMB clicks where opened in tabs.
Sorry, I mistyped: The default should be "PopupsWithinTabs=false" instead of the "PopupsWithinTabs=true" in the KDE_3_2_BRANCH. I hate to have those explicitly wanted/clicked openWindow()'s in a new tab. As long as there's not an option for it, it should behave like 3.1.x.
Created attachment 4946 [details] Patch to change default from 'true' to 'false'.
I was about to submit the same (KDE 3.2.0). Yes, I think javascript-opened windows should open as they meant - with proper size etc. and "open in new tab instead of new window" should work only for target="_blank" types of thing ;-)