All users were logged out of Bugzilla on October 13th, 2018
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?
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 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 → ---
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.
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.
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.
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. ***
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.
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. ***
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?
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. :-)
*** 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
*** 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.
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]
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. ***
*** Bug 160119 has been marked as a duplicate of this bug. ***
*** Bug 158223 has been marked as a duplicate of this bug. ***
Whiteboard: [Hixie-P0] → [Hixie-P0] bug 105547 covers at least target="..."
this would so break sites that use window.opener to talk back to the opener.
Doron: Yeah, may they rest in *pieces*.
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. ***
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.
*** 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.
*** 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.
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
TBE accomplishes this by allowing a new window to open and then re-attach it. It's a hack.
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).
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.)
> 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.
It can be done with http://extensionroom.mozdev.org/more-info/tabkiller
> 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.
Created attachment 160966 [details] testcase for window.open that can open in a tab This testcase calls window.open without a third argument. It can open in a new tab because the size is not explicitly specified.
Created attachment 160968 [details] testcase for window.open that must open in a window 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 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.
*** Bug 269942 has been marked as a duplicate of this bug. ***
(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.
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.
Component: Build Config → Build Config
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
Last Resolved: 17 years ago → 14 years ago
Resolution: --- → FIXED
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.
Since this blocks bug 138198 and bug 138198 is a duplicate of bug 55696, shouldn't this one just block bug 55696 directly?
VERIFIED, deleted hixie-p0 from whiteboard, changed blocked bugs as suggested.
You need to log in before you can comment on or make changes to this bug.