Closed Bug 103843 Opened 23 years ago Closed 20 years ago

New windows created by javascript (window.open) should appear as tabs

Categories

(SeaMonkey :: Tabbed Browser, enhancement)

Product:
SeaMonkey
Component:
Tabbed Browser
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: emmet, Assigned: jag+mozilla)

References

(Blocks 3 open bugs,
URL
)

Details

(Keywords: testcase, Whiteboard: [parity-opera])

Attachments

(3 files)

Tabbed browsing with javascript window.
24.02 KB, image/gif
Details
testcase for window.open that can open in a tab
220 bytes, text/html
Details
testcase for window.open that must open in a window
257 bytes, text/html
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4+) Gecko/20011008 BuildID: 2001100803 When a new window is created by html/javascript while keeping the old one up, there should be an option that this window should appear as a new tab rather than a new window. Reproducible: Always Steps to Reproduce: 1. view http://www.mozilla.org/quality/help/bugzilla-helper.html 2. fill in bug 3. submit bug 4. look at new window and old window...
Severity: normal → enhancement
many js created windows set an explicit size and are meant to display in a separate window, in some cases chromeless etc. Not sure i like this RFE.. it would in many cases break the designers intentions.
Many designers set fonts to an explicit size and color, but I can define them. JS windows open to explicit sizes, but I can resize them all day. Designers intentions don't matter. It's called the user agent for a reason. Why shouldn't the user have more control?
Yes, but opening in a new Tab would mean that you either: 1) Want the whole window (with the source page tab) to resize/become chromeless/whatever to accomodate for the new tab 2) Want the new tab to ignore those settings making this part of Javascript spec useless. Neither looks very interesting... I think this bug should be marked INVALID or WONTFIX.
wontfix.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
I disagree. This is a useful feature that is implemented by other browsers with tabbed interfaces.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
Then maybe a pref? In the UI, it should be stated along with the option button that some functionality of Javascript will be lost.
Not wishing to be a peacemaker, but... *Sometimes* a new window is just opened (bugzilla) and *sometimes* the window is a pop up with specified charateristics (no scroll bars etc). There must be a way to tell them apart, and, certainly, the 'normal' windows should open in a tab.
This is not only a javascript issue <a href="http://bugzilla.mozilla.org/createaccount.cgi" target="other"> will create a new window when is 'should' create a new tab
Summary: New windows created by javascript should appear as tabs → New windows created by javascript and html should appear as tabs
Emmet: Good point. But implementation would be tricky and susceptible to bugs. It would be very easy to overlook some possibilities. Anyway, I think the best solution then would be a scheme where traditional behaviour (new window) is by default, and when we detect that it doesn't do funky things with its size and decoration (toolbars, scrollbars etc) we open it as a new tab. But I think that the user should have an option of traditional behaviour - this should be a pref. Just in case.
*** Bug 104632 has been marked as a duplicate of this bug. ***
*** Bug 105436 has been marked as a duplicate of this bug. ***
Can we have two option preferences? - Open windows with no explicit size, toolbars, scrollbars in new tabs and - Open all new windows in new tabs
I agree with RC and David. I *want* to be able to force new windows into tabs. I'm just a user, not a developer, so I'll understand if there are risks with this RFE that modify the final form it takes or delay the implementation, but I would really like this feature. A pref seems like a very logical and sensible solution. I don't mind if it's only in prefs.js or whatever.
I'm tending to agree with the user pref. A developer's intentions are all well and good, but I, as the user, should have the power to dictate that the developer's "intentions" are wrong, and should be overridden. The user should know that some functionality can be lost, but that shouldn't prohibit the user from making that choice. If you won't allow this preference in, then why have tabs in the first place? It goes against a developer's intentions of wanting a new window. I don't remember this "developer's intentions" debate coming up when the request for blocking popups was issued. Of course, this might impact some design and lead to a delay in implementation, but I do believe the option should be there. Sorry for the rant... but I just don't think that "developer intention" is a valid reason not to add this option, when it's requested by many, as could very well be seen as a bug.
Target Milestone: mozilla1.0 → mozilla1.0.1
I think this should be fixed soon.
Emmet's compromise (comment #7) sounds ideal. Not only does it resolve the pesky problems described by Alexander (comment #3), it neatly divides opened windows into two groups -- unmodified and modified -- and handles each appropriately. Generally, unmodified window.open() commands are intended to direct the user to a new page, while making it easy to return to the parent. In this case, opening the page in a new tab is actually a cleaner implementation, as the tab bar makes it clear that a new "window" has been opened, and the user can easily switch back and forth between the parent and child. Modified windows generally have a very different purpose. It's often useful for the user to see the contents of both windows at the same time, and generally the intention is to return the user to the parent window when the child is closed. The latter may be lost if the new window is opened in a tab, as closing the child window would take the user to the last tab, which may not be the parent.
> Modified windows generally have a very different purpose. Yes, but... > It's often useful for the user to see the contents of both windows > at the same time, and generally the intention is to return the user > to the parent window when the child is closed. The latter may be > lost if the new window is opened in a tab, as closing the child > window would take the user to the last tab, which may not be the > parent. Err, no. The overwhelming majority of windows that have their vital attributes (presense or absense of menus, toolbars, and so on) modified by javascript are content-free nuissances that many users (albeit not all, and of course not the page hosting service) would rather not have at all. It should be a pref, but users should have the option to redirect _all_ instances of window.open to tabs. Tabs without focus, preferably. This is arguably better than disallowing them altogether (which is possible now but has no UI) because there _are_ pages out there that show useful content via window.open and opening them in tabs allows the user to select them at will. As for javascript having the ability to change whether windows have toolbars, menus, and so on, this "functionality" can only serve to limit the user; the user loses nothing by its loss. The page designer may feel that he loses something by the user's being able to easily (e.g.) hit the back button, but the user loses nothing by having this ability. And if he wants rid of such things, he can turn them off himself easily enough, as I do with the sidebar. I don't see any need to "warn" the user that functionality will be lost, since it is not the user who will lose anything (unless one wants to argue that he has lost the ability to abdicate functionality, but if he loses that by setting a preference, then it seems he has _chosen_ not to abdicate, rather than lost the ability to do so). I think it goes without saying that if the user chooses to set a preference that redirects contents that the page attempts to open in a new window to a new tab instead, he is aware at some level (if he understands what the pref means at all) that he is taking control of something the page designer wanted to control, forcing his own convenience over the desires of the page author. It stands to reason that a user making such a choice would typically not mind if as a side-effect the page designer is also unable to take away his toolbars and things. As for resizing of the window via javascript, the user can already choose to negate this by use of the maximise button (under Windows or X at any rate; MacOS 9 seems to lack a true maximise feature, for some reason) or by manually resizing the window. The script could watch for such things to happen and counteract them, but at that point the script is deliberately fighting the user's wishes, and I think the browser can be forgiven for allowing users with their prefs set a certain way to triumph over such obstinance. So, IMO, allowing the user to set a pref (e.g., to open window.open stuff in tabs) that causes pages to be sized differently than the javascript wanted, is not taking anything away from the user. If page designers complain, just tell them 95% of users never change the prefs anyway -- it's not like we're asking for window.open to be redirected to tabs by _default_.
My 2 cents: I must agree with Jonadab, I want the ability to redirect *all* window open requests to a new tab. This would be especially convenient when viewing those sites that insist on opening 5 new windows every time you try to close one of them. Not that I personally have ever seen such behavior, but friends have told me about it ;^) More importantly, it keeps all my related pages within a single browser window, as I intended. So, this should also mean that if I turn on such a feature, and a page calls open() in a window that I am closing, the call to open() should be ignored.
> Not that I personally have ever seen such behavior You've never been to GeoCities? (Okay, it's some better since Yahoo! bought them out, but it's still pretty bad.) However, the endless popping-up of stupid banners on page load and unload are another bug. (Soon it will be possible to prevent such popups on page load and unload.) But there are lots of sites out there, some of them even useful on occasion, that fire off new windows when the user clicks a link. Those you often want to see, because they often contain information that is relevant to the site. However, I want to be able to see them in a tab within the same window as the page that spawned them, since they are related to that page, and I use tabs to view related pages within the same window, as an orginasational tool for keeping related things together. To me, new window means separate topic, unrelated content. It took me about twenty minutes to realise this method of orginasation after I downloaded my first tab-enabled nightly build, and it has revolutionised my browsing experience. Now I want to be able to force all pages to comply with it.
*** Bug 105409 has been marked as a duplicate of this bug. ***
I'd like to suggest another compromise. Have a UI option to open javascript created windows in a new tab. By default, this would apply only to unmodified windows. Also have an option to disable modifications in window.open. Setting this preference would still permit window.open, but any changes to size and tools would be ignored. This would give users three choices: 1. Set "Open js windows in new tab" only. This would implement the behavior suggested by Emmet (comment #7). 2. Set "Disable window.open modifications" only. Window.open would open a new browser window, ignoring settings for size and tools. 3. Set both options. All js created windows would open in new tabs without modifications, as in Aleksander's second option (comment #3). Note to Jonadab: It's already possible to prevent popups on page load and unload. See http://www.mozilla.org/unix/customizing.html#prefs for details.
spam: set your filter for "SeverusSnape" to avoid the influx of bugmail changing QA contact of open tabbed browser bugs from blake to me. if this bug requires a reassignment, however, feel free to change it!
QA Contact: blakeross → sairuh
Beth J.: I can go along with that compromise. It seems like it would let everyone achieve what they want. Re. policies: I know, but I meant that soon there will be a UI for it (hopefully), so regular ordinary users can do it.
How about this - windows opened with JavaScript open as new windows but when instructions come from HTML (target), then check preferences and open as new tab or new window.
> How about this - windows opened with JavaScript open as new windows > but when instructions come from HTML (target), then check > preferences and open as new tab or new window. No, I want the javascript-launched ones to also be in a tab. I see _no_ reason to let pages open up new windows instead of tabs when the user desires tabs. Besides, if you were to implement things this way, soon every unscrupulous web designer will make sure to open all new windows using javascript.
HTML target= is bug 105547. This should maybe be an RFE for the Javascript part.
In my opinion comment #21 from Beth does a good job in satisfying everyones need. If one desires to use tabs one can force all window-popups to do so, and if one on the other hand does not want all popups to do so, one can set up a satisfying granular ruleset how to handle them. Also I have no worries that one has to warn a user about something, because if you select "open in tab instead of new window" from "advanced preferences" and you DON'T know what you're doing, you probably should not be using preferences at all. (And to confirm this: me too wants to be able to push ALL popups (the JS ones dicussed in this bug and the HTML TARGET="" as discussed in bug 105547) into TABS!)
Reassigning to new component owner.
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
*** Bug 125910 has been marked as a duplicate of this bug. ***
*** Bug 126753 has been marked as a duplicate of this bug. ***
Looking at the direction the discussion of the bug has taken, it might be for the best if the scope of this bug was limited to JavaScript. There is already an RFE for generating new tabs instead of windows for HTML targets. With two similar bugs, each having a different focus, maybe one can get implemented faster. After all, while everybody has a different idea of when JS popups should open in a tab instead of a window, just about everyone agrees on trapping target="_blank", so work on that could start right away while the community comes to a concensus on JS tabs vs. windows.
See, but what I want is a "NO NEW WINDOWS *EVER*" checkbox.. when I double-click the mozilla icon three times, I want one window to have three tabs. I don't just want targets trapped. Can't you just capture the call to create a new mozilla window?
> See, but what I want is a "NO NEW WINDOWS *EVER*" checkbox [...] That's *close* to what I want, but I would still like to be able to get a new window via File->New Window in the event that I should happen to want one (which does happen from time to time). What I don't want is for new windows to be created automatically without my express direction as a result of various events (such as HTML targets, Javascript, passing URLs in from the commandline or from other apps, &c). But I agree that splitting it into separate bugs is a Good Thing. If 105547 is for HTML targets, and this bug is for Javascript, is there a bug out there elsewhere for the remainder (commandline, url proxies from other apps, and so on)? If not, shouldn't there be? That would round it out so that everything is represented with specific bugs for specific issues.
maybe i'm the wierd one here, for (god forbid) suggesting that this is a DOM/Javascript issue that Mozilla should consider as a mozilla-specific feature. I realize that much of Mozilla's emphasis has been on being 100% W3C Compliant, for what its worth, but given that "Window" isn't even an official DOM object, its not exactly part of any standard that could be said to be in danger of being violated. Netscape invented Window and all its options -- everybody else just copied Netscape's implementation;the DOM doesn't acknowledge that it even exists. Its a de facto standard, not an open one. An extension to Window.open, or a new function that can be tested against [if (Window.newTab) window.newTab(url); else window.open(url);] i don't see as especially hurting anything... basically, my idea is that i want to write a javascript or cgi search engine wrapper that takes the input search string and applies it to X number of engines out there (google, yahoo, lycos, altavista, etc), but opening each one in a new tab instead of a new separate window (crowding my overfilled screen real-estate as it is) or in frames (Where if you have enough of these, each ends up so small you have to use the hard-to-use horizontal scroll bars for each one). in other words, i'm not using the tabs as a way around popup windows, i actually want to use tabs in my web application (simple though it is). similarly, i have a javascript function that "launches" X number of windows to all the things i like to see when i first log in in the morning, like slashdot, any of my webmail accounts, news from my.yahoo.com, etc...I kinda would rather that all launch as tabs in a single window than the random placement of window.open...but i don't want that feature to interfere with legitimate uses of window.open, where frame size matters (like, say, HOB.com concert frames). if there is such a function, documentation for it ain' easily reachable. the only thing i can see is the spec on the source code of the tab implementation itself... yeah, i could probably b.s. it using hidden & visible IFrames, and tweak it a bit to be M$ IE and opera compliant as well, but that's not gonna be very clean...standards-compliant, but not clean. Joe
simply put: no. a slightly longer reason: browsing is something that the user does with the aid of the useragent, in the manner of the user's choosing. If I choose to use tabs, it's *my* choice. If I choose to use windows, it's *my* choice. exposing tabs to the web content author would be a bug. if your application wants to do what you're describing, you can use xul/xbl today to do it. you haven't described anything that requires chrome privs.
Could we take the above discussion to the newsgroups, or another bug? This bug is about fixing the code so that window.open("...") and <a href="..." target="foopy">...</a> (always) open in a new tab instead of a new window when the corresponding pref is set. [X] Windows opened by the webpage [X] Only those with all decoration Marlon may have some ideas here.
*** Bug 129281 has been marked as a duplicate of this bug. ***
*** Bug 129667 has been marked as a duplicate of this bug. ***
*** Bug 129837 has been marked as a duplicate of this bug. ***
*** Bug 132547 has been marked as a duplicate of this bug. ***
This should be another pref in the Tabbed Brovsing panel. The sooner the better, too. Please. :-)
Whiteboard: [Hixie-P0]
Blocks: 138198
*** Bug 138617 has been marked as a duplicate of this bug. ***
In my opinion, the preference(s) should at least allow for the following: target="_blank/_new/..." will open ( ) in new window ( ) in new tab ( ) same window/tab window.open will open ( ) in new window ( ) in new tab ( ) same window/tab In order to achieve a relaxed browsing experience, one should not only be able to force pages that want to open as new windows into new tabs but also be able to open them in the _same_ (current) window/tab (just like regular links). For target="..." links, this is already possible, and that's great. Right now if I click on a target="_blank" link, the page will load in the same window/tab since I have the "allow webpages to open a link in a new window" pref unchecked. If I want to open the link in a new tab nevertheless, there's still the "Open Link in New Tab" entry in the context menu. It would be really nice if this option was implemented for JS windows too.
We should not expose the difference between target= and window.open to the user.
Actually, I think this should be two prefs. One under the popup panel: "Open a link in a new window" (or whatever). The other should be in the Tabbed Browsing panel: "Open tabs instead of windows for Windows opened by the Web page" (or whatever). Oddly enough both of these prefs exist. So it appears they don't work. Which means this isn't an enhancement...
Severity: enhancement → normal
Re: comment 43: Making window.open open in the same tab is bug 64560. See also bug 78037.
Blocks: window-choice
*** Bug 151444 has been marked as a duplicate of this bug. ***
*** Bug 152145 has been marked as a duplicate of this bug. ***
I have seen several websites where there is a small popup window used as a navigation bar. It is automatically rearranged so it sits besides the main window. I guess www.download.com has such a feature. With tabs this would be completely useless as the intention is to see both windows at the same time. I myself have a page where a popup window is used to display a picture when you click on a thumbnail. Obviously this window doesn't need anything like a scrollbar , menu etc. By clicking in the window it is closed, so that you can browse through the pics quickly. Earlier I created a website where a small window opened through mouseover events to show a little description. On mouseout it automatically closed, like a tooltip window. Would they open as new fullscreen tabs, their functionality would be destroyed. There are many other examples where popup windows pressed into tab windows would destroy the functionality/design of a website. I think the solution to look for parameters in "window.open" and only use tabs if there are none like window sizing or positioning would be the best way. Shouldn't be too difficult to implement this. Regards Thomas
Thomas, I do not like websites that attempt to popup a new window for any reason. If some website thinks I should see both windows at the same time, then it's a bad design. My browser window is full-screen, and thus one window will obscure the other anyhow. The functionality you describe on your own website could be just as easily accomplished by having a page with two frames. A small frame on the left could have thumbnails, and clicking on them causes a picture to display in the frame on the right. I've seen this done before. As far as tooltip functionality, there's no need to open a new window. Go to your favorite search engine and look for "overlib". I'm not sure how it works, but I haven't found a single "open" statement in it, so apparently it doesn't use windows to implement the functionality. As far as looking for window sizing or positioning, all of the pop-up and pop-under advertisements use sizing and/or positioning, so this is *exactly* the case where I do not want a new window being created. So, if I'm marking an option to cause *all* new windows to be created within tabs, then I really do want *all* of them created within tabs. And eventually, I hope the existance of such a feature will cause web site developers to stop designing sites that open new windows. :^)
i second the dislike for pop-up(under)-windows in general. whatever functionality the author would like to achive... it could certainly be done otherwise and in a cleaner attempt. take http://www.litepc.com/xplite.html for an example.. hover the items in the bar (products, etc) and watch the menus appear. those menus can also be fed with images or whatever one would like. i see NO need at all for such popups. and since it shall be an optional preference, those who really want to have them can still /not/ enable this feature. that's what preferences are for, aren't they?
When I open a browser I expect it to behave like other programs and use only the screen space I've allowed it via window sizing. It should not do anything to any screen space outside those boundaries. This includes opening uninvited new windows. When I want or need new windows I will authorize or open them. It's my personal computer.
So, what's the final word (how, when) on this?
> I have seen several websites where there is a small popup > window used as a navigation bar. It is automatically rearranged > so it sits besides the main window. I guess www.download.com > has such a feature. If you want these sites to be compatible with tabbed browsing, you'll need to file a separate bug for them under the Tech Evangelism component. Otherwise, please remember that tabbed browsing is, despite being obviously superior to the old way of doing things, still going to be strictly optional for the forseeable future.
I definetely definetely would like this to be implemented. For some sites (like those that have control panels or the like in a seperate window) it might be inconvenient or buggy, but Mozilla is, in my experience a highly customizable browser targetted more towards power users. I think it should be implemented with the rest of tab browsing, as an option that users who like it can use and those who don't can turn it off. I might point out that Opera is capable of opening new windows in "tabs" though, so it might be a good idea to implement to help convert the Opera heathen.
With the number of invasive pop-up ads rising every day, the ability to cage window.opens in tabs is invaluable. The argument of not wanting to compromising javascript functionality is moot to me. Under Preferences->Advanced->Scripts & Windows there are already options that limit obnoxious javascript features. The argument that it would be difficult or hackish to implement also seems weak since there already exists an option to disallow webpages to "Open unrequested windows". If that works there is obviously already a check whenever a window.open happens...why not just add an option that says "Open unrequested windows as tabs."
because this is about windows you WANT to have... for me it means: i want to block unrequested windows anyway (already doing this fine). but now i want all the other new opening windows (that i usually request manually) to appear in tabs. what you suggest would imho be another enhacement. [btw: the pop-up blocker just checks for on onload and onclose events (that's while the page loads or when it gets closed), so manually requested 'onclick' can still load. unfortunatly 'onMouseOver'-ads still can load too.. but this matter does not belong into this bug here]
I think this report has a much too wide scope and should be split into two bug reports. One for the handling of target="..." in A anchor and one for the handling of window.open is javascript. The handling of the target option looks quite simple to me. If i have decided to use tab browsing and ask the middle button to open links in new tab, i also want (at least most of the times) links with target option to open in a tab. Once "bug" <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=102132">102132</a> is fixed, i will have no problem to detach this tab if i want to. Refinment of default behavior could be added as proposed by snebeling@yahoo.com (<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=103843#c43">#43</a>). The author of this comment says that the behavior i am asking for is already present in Mozilla. I would love that to be true but i have never seen any mozilla build doing it right (and build 20020711, rv 1.1a+, still opens links with target="_new" in a new window whatever i try to do to prevent this). The handling of window.open is much more complex. Apart from the f***g b***s who writes the ad popups, almost everyone agrees that we should allow users to discard as many ad popups as possible. Some comments give examples of "valid" uses of popups. I think that most of them (if not all) are just the result of bad design. The authors of such pages (or web applications if you prefer to call them that way) want to force their way of thinking to the users. User should have and keep control on what a site can do on thier desktop. If disallowing window.open breaks your application, it's your fault not Mozilla's or user's one. Of course such pages exist (and many more will be created) and we need a way to deal with them. I think that the control of scripts should be more fine grained than it is currently. Allowing/disallowing window.open should be possible at a site level or even at a page level. Users must be able to quickly change mozilla behavior, having to select prefs and dig your way down to scripts and plugins (bad name by the way, not explicit enough) is not an acceptable solution. This setting should be as easy to change as cookies and images blocking. Having this feature added to the tools menu would be nice. In fact i would like to have buttons to block/unblock cookies / images / javascript / plugins / popups / ... for the current page/site. This would require to have customizable toolbars but that's standard stuff in today GUI toolkits. (maybe i should look if there is already a report for such an enhancement and fill a RFE if not) Just my (long) 2 cents :-)
Well my concern isn't too closely related to popups. I have them disabled in Zonealarm 3 and the "open unrequested windows" disabled in Mozilla, so I very rarely get popups anyway. What'd I'd like more to see is an option to change the behavior of valid "open in new window" links to load them in tabs instead. You can of course do this by middle clicking or control clicking, but unless you know in advance that a link is an "open in new window" link, you probably wouldn't think to do that. In regards to trapping popup windows in tabs, that'd be nice but probably unneccesary. Most people who know anything about controlling popups block them anyway, and even if this feature were to be added it should probably be filed a different bug report since there are so many differet ways popup windows can be spawned.
> What'd I'd like more to see is an option to change the > behavior of valid "open in new window" links to load them in tabs instead. You > can of course do this by middle clicking or control clicking, but unless you > know in advance that a link is an "open in new window" link, you probably > wouldn't think to do that. I totally agree with you. Once you have decided that ctrl+click or middle-click should open link in a new tab, any simple click on a "targetted link" should also open it in a new tab. This behavior shouldn't be too difficult to add.
*** Bug 142214 has been marked as a duplicate of this bug. ***
*** Bug 159091 has been marked as a duplicate of this bug. ***
Lots of sicussion and some miscommunication here. Let me attempt to summarize and then give an extra E 0.02. There are pages that automatically open pages in other windows. We want it made possible that these are redirected into tabs instead of new windows. These open actions come in four flavours: -Javascript opened normal windows -Javascript opened limited windows -HTML target="_blank" opened windows -Obscure stuff (proxies or whatever) The HTML opened windows are apparently dealt with in bug 105547, so no reason to keep discussing the details of that here, just ensure the eventual prefs options are consistent. The problem with the javascript limited windows is that some limit the toolbar and resize options and such. Furthermore, web designers sometimes use these windows as part of their GUI. If these are put in tabs their site can be impaired. Lastly, some JS opened pages want you to go back to their parent on closing. The general agreement seems to be 'too bad for the designers, they'll find another way, and too bad for the standards, they don't even seem to cover this.' The idea (AFAICT) is that you can more easily put everything related to topic X in one window and topic Y in another and so keep your browsing organized without leading to loss of data because some windows can't open or having to pay attention all the time and use context menu-based opening of links. How to implement then? 1 decide if this applies to all windows opened (not just OnOpen and OnClose). 2 decide if you wish to treat limited JS windows differently than normal ones. 3 decide if you wish to provide alternatives for the limitations. 4 decide a form for the preferences option. 5 patch the code sections that can lead to a new window and make the prefs. My own feelings are: 1: all of them, 2: no, 3: center the window in the tab, possibly gray out some of the UI when the tab is selected, 4: use a single setting or use radio buttons, and for each of the four flavours allow the user to choose from 'normal,' 'tab instead of window,' 'same tab or window' Only problem is that this may cause confusion with the existing scripts and windows prefs and tabbed browsing prefs. Personally I would be quite happy if there was just one option of shifting everything into tabs, since I have no need to fine tune it based on what language causes the new window. Cage the lot of them.
*** Bug 160119 has been marked as a duplicate of this bug. ***
Blocks: 150340
Blocks: 146873
Blocks: 161466
*** Bug 158223 has been marked as a duplicate of this bug. ***
Summary: New windows created by javascript and html should appear as tabs → New windows created by javascript should appear as tabs
Whiteboard: [Hixie-P0] → [Hixie-P0] bug 105547 covers at least target="..."
Blocks: majorbugs
this would so break sites that use window.opener to talk back to the opener.
Doron: Yeah, may they rest in *pieces*.
There's an XUL App at http://www.cc-net.or.jp/~piro/xul/_tabextensions.en.html that solves this problem. It has half-a-million customizations possible so that some combination of preferences should provide the behaviour that you want. I've only been running this for a day but it's the most complete implementation of the tab handling comparable to Crazy Browser that I've found. Some of the options for opening in tabs are in another package called Context Extensions which has a menu-based system for adding additional Context Menu [right-click] options. They can be application programs or javascript programs. The menus provide samples and help [there's a button there for help but I didn't use it].
Well thank you Michael, that's excactly what I needed. Now if that had been coded into Mozilla that would 'fix' the 'bug'. Anyways, I'm using it now and it seems to work great.
*** Bug 168195 has been marked as a duplicate of this bug. ***
Doron: why would this break sites that use window.opener? window.opener can be any viewport or frame.
Jesse: It depends on the implementation
*** Bug 173135 has been marked as a duplicate of this bug. ***
QA Contact: sairuh → pmac
I don't see why it would break any sites. In fact I can't tell how they could tell the difference.
One example would be a site that uses a smaller window sitting on top of the main window as a navigational tool. The smaller navigational window stays active and you click links within it, while the content shown in the "main" window is changed. (Yes, this is a "bad" way of doing things - using frames would be much more efficient.) But, the fact remains that in this instance using tabs would break the functionality since you can't the content of both tabs at the same time. (I'm not arguing that this is a sufficient reason against implementing new tabs, just pointing out a situation where opening a link in a new tab, rather than a window, would be sufficiently against the site design as to make it not function properly.)
Oops, my last post was slightly off topic - it didn't address the question about window.opener specifically. I guess that teaches me to read posts in context...
In the absence of explicit permission, no app has any business opening a window outside the bounds of that app's screenspace. I allocate screenspace to an app, and that's all it should have. The rest is my business. It's my personal computer. If some stupid web sites must have separate windows for menus, those menu windows should automatically, at least via a pref if necessary, be constrained to open within the boundaries of the window that spawned them.
Ideally, the solution to this would always allow an option to override the blocking/redirecting behavior. For example, one could always right-click on a link and choose, "follow link allowing new windows," to allow whatever javascript is present in that link to execute, creating a new window if window.open is called. Additionally, I would like the option in this case to allow me to specify whether the link will open into a new window (for those cases where navigation requires it) or a new tab (the common case) - while retaining the ability to have most new window requests open into the existing window/tab (or into new tabs, if that's what I've requested). I guess this belongs equally under Bug 64560. Maybe I'll repost there as well.
*** Bug 184286 has been marked as a duplicate of this bug. ***
Why not leave it to the user, to determine, weather he wants another tab or not? means: middle-click -> new tab left-klick -> open new window in the old tab.
> Why not leave it to the user, to determine, weather he wants another tab or not? > means: > middle-click -> new tab > left-klick -> open new window in the old tab. izorg, There's already a preference to set middle-click to either open tabs or windows. And right-clicking will bring up a menu that lets you choose a tab or window. This PR is for handling javascript-based window open events - windows opening when you haven't clicked anything (ok, I suppose sites can also have these when you click something). The most common examples of this are popup and pop-under advertisements.
*** Bug 185660 has been marked as a duplicate of this bug. ***
*** Bug 185743 has been marked as a duplicate of this bug. ***
*** Bug 186211 has been marked as a duplicate of this bug. ***
*** Bug 187703 has been marked as a duplicate of this bug. ***
guess i finally get to contribute... go to about:config find the setting browser.tabs.opentabfor.windowopen make it TRUE hope that works as well for you as it did for me. dunno about target=new.
I got sick of reading comments. I want to point out how much this option could break one specific type of website: Web Applications. I agree that any "normal" website should never need to pop-up a window. There are framesets for navigation if you have such a heavy interface that it cannot be reloaded with every page (ugh). But my application uses nearly-chromeless popups (requested only, of course) to present information in an application-like manner. These pop-ups allow me to delegate information into streamlined windows. I even use JS to make the "dialogs" modal - forcing focus back to the top window. Allowing the user to place these popups into a tab would seriously affect the way my application works. One possible way around this would be to not force popups that are initiated from secure (https) websites into tabs. Since most web-based applications are secure, this should help.
Ultimately, the user should control how the data appears. Making it a site-specific option would be more convenient.
*** Bug 211936 has been marked as a duplicate of this bug. ***
To Clarence Risher (#86): > go to about:config > find the setting browser.tabs.opentabfor.windowopen > make it TRUE > hope that works as well for you as it did for me. Which browser, which version? Doesn't work for me (1.4, Linux).
To Phil DeJarnett (#86): In an environment without a window manager (e.g. kiosk setups) there is no new window to open. Thus, a window.open() simply gets lost. With 'browser.tabs.opentabfor.windowopen=true' you can use the tabbrowser as window manager, so the popups are not completely lost. This is just another example that the last control must always be kept to the user. The web author simply doesn't know how and with what device a site/application is viewed.
Work-around: Tabbrowser extensions:http://white.sakura.ne.jp/~piro/xul/_tabextensions.html.en will let you set javascript windows to open in a new tab. FYI
and so does Multizilla: http://multizilla.mozdev.org
One thought, that may be of some use for some people... Behavior of the new_tab vs. new_window options should be able to be overridden on a per-site basis.. That way, if you have a site that specifically requires a pop-up/new window to function as designed.. you can allow it, if you wish, on a permanent basis ("Trusted Sites").. similarly to how you can already allow this to work with the pop-up blocker. That way, you can specifically adjust the behavior for the sites. This can work in reverse as well.. Depending on the pref and how it's set, some particularly troublesome sites, could be captured into tabs over windows on a per-site basis. "Allow New Windows For..." and "Always Force New Tabs For" respectively... This should allow the last bit of user control needed to prevent irreversable breaking of sites, and allow the new options to be flexable. Also, target milestone for this bug is Mozilla 1.0.1, which has already come and gone.. Any idea as to when this bug will become "assigned" to somebody to fix? -- Wolf
There appears to be much technical discussion as to why this bug should or can't be fixed. It is better to rethink of how tabbed browsing is used. Someone brought up an important point (possibly in another related bug report) about constraining to current screen space. This is why a user would prefer to use tabbed browsing. So we shouldn't think of opening a tab as something different from opening a new window, but rather as alternative default behaviour. For instance, I wish the familiar ^N opened a new tab, with perhaps Shift^N opening a new window. If the user has chosen to use the tabbed browsing as default behaviour, then any action that would normally have created a new window should instead create a new tab. Creating a new window would then be a priviledged action and treated similarly to popup blocking. The times when a new window is actually need by an application so the user can see both simultaneously usually specifies the new window's characteristics. This information can be used as the default determination as to whether a new window or tab is to be opened. Further permission could explicitly be granted by the user for a specific site (or I'd prefer URL prefix). The decision as to whether a new window or tab is to be created should not be made at the time of user input event, but rather deferred until the new window/tab is to be created, if ever. How this could work: I Ctrl+Click (or middle-click) a link which has JavaScript attached. It is flagged that tabbed browsing is to be used for the processing of this event. If this action ultimately results in navigation (e.g. form submission, window.open(), etc.) create a new tab as the context to complete processing. If no navigation (e.g. reset form), no new tab.
a - tabs are an advanced user feature b - only a subset of tab-using users desire pop-ups to be opened in tabs c - Mozilla includes pop-up blocking features d - opening pop-up windows in a background tab has potential to confuse users e - no Mozilla.org driver has expressed an interest in adding this functionality f - this functionality is fully implementable via XPI (and already implemented) g - Mozilla's tab functionality is superior to Internet Explorer's Listed above are six facts, which I believe to be reasonably indisputable. 1 - Given (a) and (b), this feature request would only be used by subset (b) of small subset (a) 2 - Given (c), the occurences of unwanted javascript windows are reduced, reducing the need for this feature. 3 - Given (1), (2), (d), (f), and (g), no driver is likely to change interest level (e). 4 - Given (1) and (3), significantly less effort would be required for the people so interested to install a tab-browsing extension and for Peter Annema to mark this bug WONTFIX than would be required for Mozilla.org to implement this feature, document it, maintain it, and support it though the current unofficial-official channels.
TBE accomplishes this by allowing a new window to open and then re-attach it. It's a hack.
I usually work around this using by opening links with the middle mouse button (or ctrl-enter?). This though doesn't work when a link is a javascript. Mozilla then open a new tab, which doesn't run the javascript correctly. Where I want unrequested popups, it is in most cases OK to open a new window, but it might be annoying in some cases.
Opening pop-up windows in new windows has a good deal of potential to confuse users, too. Consider the case where: - maximised window A contains a link which opens another page in named window B - the user reads B, then switches back to A leaving B open for later - A now fills the whole screen again - after long enough to have forgotten about leaving B open, the user clicks on the same link, or another link in window A whose target is also B - the new document loads in B, but since A is maximised, no change is visible on the screen! In this case, tabs are actually clearer than opening new windows. This isn't just something that can occur with naive users-- it's happened to me in the past. Also, can this bug be renamed? Not all the dupes are about JS opening new windows (some are about target="_blank" and so on).
> opens another page in named window B ... the user reads B ... > another link in window A whose target is also B Why would Mozilla have to honour anything to do with "same targets" when we implement this? Could we just open up windows C (and D, E, etc.)? Or, if we do honour targets, all we need to do is switch focus to the targeted window. > Also, can this bug be renamed? Not all the dupes are about > JS opening new windows (some are about target="_blank" and so on). I just finished looking through the activity log, and I see the problem. It used to include HTML, but was change on 8/25/2002 - at which time the whiteboard was modified to mention that bug 105557 covers the HTML side of things. However, I find that confusing at this point, especially since HTML bugs *have* been duped to this bug - one, ironically, by the same person who made the summary and whiteboard changes within the same hour. So as to avoid a considerable housecleaning chore of "unduping" all of the non-javascript bugs that have been duped here, and re-duping them elsewhere, I'm reinstating the original HTML portion of the summary and setting bug 105547 as blocking this bug.
Blocks: 105547
Summary: New windows created by javascript should appear as tabs → New windows created by javascript / HTML should appear as tabs
It doesn't make a whole lot of difference that bugs were duped to this one instead of 105547 in the past. These are seperate issues, 105547 being a bug with the current HTML new window implementation, and this one being an enhancement request with regards to a javascript function, which may or may not be wanted by drivers. Seperate bugs for seperate issues, please.
No longer blocks: 105547, 146873
Severity: normal → enhancement
Summary: New windows created by javascript / HTML should appear as tabs → New windows created by javascript (window.open) should appear as tabs
Target Milestone: mozilla1.0.1 → ---
> Seperate bugs for seperate issues, please. Then please clean up the misreported duplicates appropriately. Otherwise this bug is a complete mess. If you don't want to take the responsibility, then the previous solution is still better. Also note that the original summary of this bug, as filed by the reporter, specifically mentions both javascript *and* HTML.
What I would like to see is the ability to do _everything_ in one window. This includes viewing javascript windows with a specified size in a tab. This would be, in my opinion, the best possible solution. I have created an gif to show what I would like and will have it up in a minute. Then adding a button to make the windows a regular full sized tab could be added to the tab bar.
This is an example of what I think users should have the ability to do.
Scott: That's MDI, which is covered by bug 60775. It's different from tabbed browsing, which is what this bug is about.
>Scott: That's MDI, which is covered by bug 60775. It's different from tabbed >browsing, which is what this bug is about. Well, I don't think it is 60775 exactly; if a new window is specified to open, it would open in a new tab - this is exactly what has been specified in this bug. If the window was a resizable window, it would create a new tab and create a resized window in that tab just like as shown in my image (it would act exactly like if you had a new window, just opened in the tabbed window area) - I'm guessing that's what MDI is? The second part is just an alternative to opening in a new window.
Tabs, by definition, all have the same size. When you have windows inside windows, whether or not there exists a UI for switching to those windows, what you have is called MDI. Opera, for example, implements MDI, not tabs. (The two are pretty much mutually exclusive, although similar enough that they can be used as each other to some extent if you don't do anything special.)
OK, I see what MDI is now. You are saying there would be no way to use tabbed browsing and MDI together? The thing is, if you force everything to open in a new window, you _will_ have display problems with some windows. If you only open normal windows in tabs, then you don't get what was being asked for - the ability to open _all_ new windows in a new tab. I don’t see why it wouldn't be possible to use MDI only when you have a window that is specified to have certain dimensions, and normal tabs for any other URL set to open in another window. This, in my opinion, is the only solution that allows you to open everything in tabs without display issues. Here is why I think this belongs here: An idea was given to allow all URL's to open in tabs instead of windows. A possible problem was that some windows wouldn't display properly; the solution given was to make an exception to the rule. I don't find this acceptable, as it really doesn't solve anything. The original poster of the bug mentioned "javascript (window.open)"; 99.9% of the time this will open in a window with a fixed size (or else there usually would be no point in using javascript)- this means that with the solution that has been given, these would not open in new tabs but new windows. That is definitely not what was asked for. This was the only solution I could come up with that does what is asked for and takes care of the potential problems. >Tabs, by definition, all have the same size. When you have windows inside >windows, whether or not there exists a UI for switching to those windows, what >you have is called MDI. Let's face it, regardless of definitions, to the end user it doesn't matter if it is a full sized tab or a window selected by a tab. If it looks like tabbed browsing, tastes like tabbed browsing, smells like tabbed browsing, acts like tabbed browsing, but is slightly different in one area - it is still a tabbed browsing for all practical purposes. Yes it might technically be different, but what the person in the end sees is the same thing with more capabilities.
> it is still a tabbed browsing for all practical purposes. All practical purposes except one: implementation. Since Bugzilla is about managing issues for the people who are going to implement them, that's what matters here. :-)
*** Bug 223754 has been marked as a duplicate of this bug. ***
"Opened: 2001-10-09 07:47 PST", todays date 2004-02-02. So far 158 votes, tons of dupes, but not a single patch. You could keep waiting, and waiting... and waiting... waiting... some people call it the World Wide Wait (http://www.google.com/search?q="world+wide+wait") some people like to use mozilla more than wait for it. I'm one of them. I have a celeron 300 with 32mb, I wait enough. Start enjoying, stop waiting: multizilla.mozdev.org this bug and many others *FIXED* put your votes on a bug that needs fixing, put your effort into something that's worth it. (pulling vote because for me, this bug _is_ fixed. I did enjoy reading this bug though, good exchange of ideas about author v. user)
*** Bug 234077 has been marked as a duplicate of this bug. ***
I'm not sure about splitting the HTML and JS versions of this bug; shouldn't the behavior be consistent between the two? All I want to do is have the option to open new windows in tabs instead of windows. In particular (though not entirely limited to), I want to be able to open a new tab from a bookmarklet. Maybe a decent interim solution for bookmarklets would be to add a _tab target for window.open?
that's an *awful* idea. web sites should not be able to force users to use tabs.
note that bookmarklets run in the context of a web page. if a web page can't do something, then the bookmarklet can't do it either. if the bookmarklet can do it, then a web site will do it.
If tabs are disabled, then it would just open in another window. Besides that, how is opening in a new tab any more *awful* than opening a whole new window??
for one, we don't have any concept of disabling tabs.
(In reply to comment #111) > Start enjoying, stop waiting: > multizilla.mozdev.org Sorry, multizilla adds too many stuff to mozilla and makes the hole application _very_ astable, this is no solution for me. I would really prefer an solution on side of mozilla and my preference as user is to really have all windows the same way like opera in one thread, doesn't matter where i surf or what i do. You would do it pretty if you have a preference wheter move all new windows into tabs or only javascript popups or let them be in standard way.
> for one, we don't have any concept of disabling tabs. Oops, I was thinking of Opera there. My second point remains, though: how are tabs worse than windows? And here is a can of worms: Shouldn't bookmarklets run under a different, potentially less restrictive, security context?
*** Bug 247705 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > many js created windows set an explicit size and are meant to display in a > separate window, in some cases chromeless etc. Not sure i like this RFE.. it > would in many cases break the designers intentions. That is why it should be an option.
This testcase calls window.open without a third argument. It can open in a new tab because the size is not explicitly specified.
This testcase calls window.open with a third argument. It must open in a new window because the size is explicitly specified -- if it opened in a new tab the specified size would not be honored.
Whiteboard: [Hixie-P0] bug 105547 covers at least target="..." → [Hixie-P0] [parity-opera] bug 105547 covers at least target="..."
re comment #124: > This testcase calls window.open with a third argument. It must open in a new > window because the size is explicitly specified -- if it opened in a new tab > the specified size would not be honored. Are you an avid tab-user? I am and I don't want the size to be honoured. In fact I use a frame-based window manager that force-fits every window into the frame, so that the size will never be honoured, no matter what kind of tricks web designers try to pull off. My desktop is not a web designer's playground. I want everything neat and tidy and that requires that all of my browser windows are tabs within Mozilla. I think most people fall into one of 2 categories: People who always use tabs and people who always use new windows. Everyone I know falls into one of these 2 categories. I believe that people who combine both are the rare exception and people who want the web designer (rather than themselves) to make that choice for them are even rarer. When I want a new window I use "Open Link in New Window". The rest of the time (which is practically all of the time) I want a tab. Why is honouring the size important anyway? There are 2 possibilities: a) the requested size is larger than the browser window in at least one dimension b) the requested size is smaller than or equal to the browser window in both dimensions Because almost everyone uses the browser maximized, case a) is equivalent to "the requested size exceeds screen dimension(s)". Do you really want to create a browser window that doesn't fit on screen? Does Mozilla even do that? If it does, that's a bug. If it doesn't, then it's already not honouring the size request. And in case b) there's nothing lost by using a tab, as the tab is larger than the requested size and so can display everything that it should. If you're worried about breaking the web designer's formatting, then the tab's useable area could be constrained to the requested size (as if the whole content was put into a div with the given dimensions and overflow:scroll). There's absolutely no need to use a window in favour of a tab, just so that the rendering area's dimensions can be set to be smaller than the browser window.
It coult be done as a third option in the popup-manager: for a site: [x] allow popups [ ] open as a new tab [ ] no popups and the same for the default-value This would keep everyone happy I think. I totally agree to the ignoring the windows-size. The user does override the designers decision with using tabs, with using crtl+[+]/[-], with the image-blocker, ... and this is the user's choice to override this.
> [x] allow popups The terminology would have to be changed - as is, it's unnecesarily confusing with "Block unrequested popup windows".
(In reply to comment #125) > Are you an avid tab-user? I am and I don't want the size to be honoured. No matter what anyone wants, we need testcases for these two very different cases that people keep distinguishing between.
Put me in the same camp as haferfrost: my desktop software should obey my wishes (no new windows unless I ask) rather than those of some web designer. > [x] allow popups > [ ] open as a new tab > [ ] no popups This UI wouldn't allow a user to block popup ads yet still see "requested" popups in a new tab. Either the two options (block unrequested, and popup as tab) should be separate, or if grouped together, the middle option needs to be split into "open all popups as new tab" and "block unrequested, open requested popups as new tab". My guess is that it's clearer to present two separate options.
This bug ought to be closed and/or duped to 172962; the functionality to divert JavaScript popup windows into tabs has been added to the Aviary branch. Set browser.link.open_newwindow.restriction to the following values for the following behaviours: 0 - force all JavaScript popups into tabs 1 - allow all JavaScript popups to create new windows 2 - force JavaScript popups with window features into tabs The new Tabbrowser Preferences extension has a user interface for this pref, which appears in all Firefox Aviary builds newer than 2004100[5-7], IIRC.
> This bug ought to be closed and/or duped to 172962 Definitely not. That is a Firefox specific bug. This bug is for Mozilla (Seamonkey). There should be no duping in that direction going on.
(In reply to comment #131) > Definitely not. That is a Firefox specific bug. This bug is for Mozilla > (Seamonkey). There should be no duping in that direction going on. My mistake. But at least 172962 should be referenced; Firefox's code could be used as a model for implementing this in Seamonkey.
Depends on: 172962
*** Bug 269942 has been marked as a duplicate of this bug. ***
My bug report was marked duplicate of this one. However, this one seems to cover only JS-opened windows, whereas my one was about *all* kinds of window open: * Explicit click/return on target=_blank links * All kinds of JS (or Flash or whatever) opens * External opens (command line, click on URL in mail, ...) * About, help, etc. * History, bookmarks, ... My original bug report: If I opt for "tabbed browsing", my intention is to never have more than one browser window open (that's the way it works in Konqueror): There should at least be an option to open *all* new windows as new tab's instead, no matter if they are opened by clicking (or hitting return) on an "open in new window" link, opened as popups or by javascript, opened externally, opened from mail, bookmarks or history, or opened implicitly (about, help). I don't want to clutter my desktop and my taskbar with a dozen mozilla windows and icons, that's the whole reason behind tabbed browsing, isn't it? This is especially important for popup's, I want to have them grouped in the same window together with their parent, not in separate windows.
(In reply to comment #134) > If I opt for "tabbed browsing", my intention is to never have more than one > browser window open Sounds like bug 227241.
It's not a duplicate of bug 227241. First of all, that bug targets Firefox, not Seamonkey. Secondly, that bugs has been marked as a duplicate of bug 172962 (also targetting against Firefox) and THAT bug has to do with where to open URL called by other applications specifically.
Blocks: 269942
Can anyone show me a JS link that still opens a new window if the according pref (browser.link.open_newwindow) is set? Both the backend in bug 172962 and the prefs UI in bug 161466 have been checked in now. Otherwise I believe this can be marked fixed.
Whiteboard: [Hixie-P0] [parity-opera] bug 105547 covers at least target="..." → [Hixie-P0] [parity-opera]
Note: If you want window.open calls that request a specific size to open in a new window instead of a new tab, you can set browser.link.open_newwindow.restriction to 1. This behavior is tested by the second attached testcase in this bug.
Component: Tabbed Browser → Build Config
Product: Core → Firefox
Version: Trunk → 1.0 Branch
I am reseting this bug to the core. It does not seem that any of the last comments explains the change to Firefox.
Product: Firefox → Core
Version: 1.0 Branch → Trunk
Component: Build Config → Tabbed Browser
I don't know JS, but maybe the "zoom in" link (For me, most JS links are green due to my userContent.css, which is how I usually know any link is JS.) for the motherboard image on http://www.pcchips.com.tw/PCCWeb/Products/ProductsDetail.aspx?MenuID=92&LanID=0&DetailID=298&DetailName=Specification When I click that link in trunk or 1.0.3, Moz/FF seem to reload that original page, and not give me the enlarged iimage. Doing the same in box stock Konqueror 3.3.2 in Knoppix loads a larger image in a new window.
@ #140 When I click that link, I go to a page with the "zoom in" link. Clicking that link makes FF (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050505 Firefox/1.0+) show a yellow bar stating that a the page tries to open a popup window. Clicking Options / Show http://...... gives me a new tab with an enlarged picture.
Felix and Steve, I don't think anyone can change the behavior on the aviary branch any more, if it doesn't fully work there, because drivers now only accept security fixes on the branches. So morphing this into a Firefox 1.0 branch bug won't help. If you want a UI for the .restriction pref you should perhaps file a new bug (although I guess that it might get wontfixed). As Zarco shows with trunk FF and I can confirm with the Suite, this works even on the strange popup-zoom-in links of PCChips (they don't seem to use window.open) which are redirected as they are supposed to. Resolving fixed.
Status: NEW → RESOLVED
Closed: 23 years ago → 20 years ago
Resolution: --- → FIXED
No longer blocks: majorbugs
See also Bugzilla Bug 121969. Have you tried the SingleWindow extension and if so, did it work? Time to look at these from the "bigger picture" rather than a bunch of separate little things. They are all little, similar glitches in tabbed browsing interface fixed by different extensions in different ways. There are many many different bugs about single window mode or lack of single window mode functionality; many fixed by this extension. There are also many other simple extensions to fix shortcomings in tabbed interface which should be basic to the program and would require little effort to implement based on the simple extensions already in existence.
(In reply to comment #142) > Felix and Steve, I don't think anyone can change the behavior on the aviary > branch any more, This looks like a trunk bug according to the field at the top.
Keywords: testcase
Since this blocks bug 138198 and bug 138198 is a duplicate of bug 55696, shouldn't this one just block bug 55696 directly?
Product: Core → SeaMonkey
VERIFIED, deleted hixie-p0 from whiteboard, changed blocked bugs as suggested.
Blocks: 55696
No longer blocks: 138198
Status: RESOLVED → VERIFIED
Whiteboard: [Hixie-P0] [parity-opera] → [parity-opera]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: