I think that would be good to have some function that opens a page in a new Tab, something like a window.openTab() or <a href="url" target="_tab">. So developers could be able to use this new feature on pages.
*** This bug has been marked as a duplicate of 104204 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
Please note that bug 104204 specifically addresses opening a new tab from the command line, not from within a page. I don't think this is a duplicate.
I thing anything like window.openTab() have not to be implemented! It relies on the user prefs, if new page should be open within new page or new tab. I agree this is not duplicate of 104204.
I don't see why developers can open new windows today and should not open a new tab, I don't see any problem in give this option to the developers, I believe that if it was possible we would see some good aplications and some awfull aplications, just like it is with the window.open today.
Yeah, it's not a dup. (Oh boy, ad spammers will love this one! Why open one popup window, when you can open three background advertisement tabs :-]
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
"Just because you can, doesn't mean you should." Michael Crichton, Jurassic Park
Summary: How to open new Tab from a link → [rfe] window.openTab() and <a href="url" target="_tab">
oops - i meant to dup against bug 103843
I don't think that's a good idea to limit the browser features just to prevent the bad use of then (ad spammers or something else). window.openTab(url) would be a good feature, imagine if http://www.penny-arcade.com has a checkbox named "open links in new tabs" it would be amazing cause you would be able to open the strip and the links inside the main text in background tabs while you read the main text. Making it a preference of the browser is not the same thing... And also, you have Mozilla evangelization... this checkbox "open links in new tabs" could be "open links in new tabs (Mozilla compliant browsers only)" ;)
Well, the Sidebar is a "nifty non-standard feature" that we support, don't we? The window.sidebar.addPanel() exists. I agree that we should follow the standards, maybe there's a way to include this feature without injuries on the standards, I don't know :( What I would like in mozilla is just something like the window.sidebar.addPanel() for Tab Browsing...
Had I been paying attention a year and a half ago I might have objected to that as well! I would say supporting non-standard things is nearly (but not quite) as bad as not supporting standard things. But then again, that's how progress is made sometimes. So in that spirit, how about this solution: Instead of a new function, like openTab(), why not add a new flag in the windowFeatures part of the window.open() function. Something along the lines of "usetab=yes". It then would act more like a suggestion to the browser. Browsers that don't support tabs would (or should) ignore the "usetab" feature and just open a new window. Calls to window.open() without the "usetab" feature would work the way they do now.
I don't like this idea as described in the summary. ([rfe] window.openTab() and <a href="url" target="_tab">) In my opinion it is enough to have and we need a pref so the _user_ can decide to open new pages in tabs or in new browser windows. (I think bug 103843) It is the decision of the user to use tabs or not. I, as a user, want to decide it. With this feature we're taking this decision from the user and giving it to the homepage developers. I personally use tabs but I don't want to be forced to use them on some pages. IMHO developers can open new windows so the old content stays in the background. This can be very useful for navigation or so... A lot of people who do not want to use tabs and are forced to use them because web developers want them to will be frustrated because they would often close the complete browser window (with all tabs) when they just want to close the current page, because they aren't used to the way tabs work. Offering this great feature to users is the right way, forcing them to use it isn't. I think we're going the wrong way to a userfriendly browser when we implement this. My suggestion for this bug is wontfix.
Ok, I agree with you that: "A lot of people who do not want to use tabs and are forced to use them because web developers want them to will be frustrated because they would often close the complete browser window (with all tabs) when they just want to close the current page, because they aren't used to the way tabs work." But I dont think that open new windows is the better way for page developers to "mantain the content", the user is forced to a great change in the context, a completely new browser opens just above the website that he was navigating. I'm not saying that with new tabs it would be different, depending on how this was implemented, the loss of context would coontinue the same as we have with new windows. So, here is my suggestion: If we give the option to page developers to open an url on a new tab, this tab would be opened but not gain focus until the user intensionally clicks on it.
I think just a user pref is enough for open all new links in a tab.. that is all we need for this.. if you want it you got a choice.. there that is how it should be implemented only.. as a user pref. We dont need a new function.. and deviation from the standards is not acceptable at this point for tab browsing.. vs new open windows.. besides the context window already has the open link in tab, and also the user pref for loading it in the background exists instead of focus.. this [RFE] is bogus because we already have a way to let the user decide. I'd say wontfix is good. (context menu for those not knowing is the right-clicking on a link) - which has open in new tab.. and tabs browser pref now works for opening in a tab in background. The user has choices this way.. at least 3 ways to open links already. Just my $.02 -dman84
I understand this is a newgroup issue. oh, yeah to give you an analogy: consider Sun vs Microsoft about Java in Windows. Microsoft didn't follow the exact standard implementation.. Sun said you should.. now we have C# which is MS crapping proprietary version of Java.. Mozilla should not be adding functions here and there just because it would be cool to a standard that it is not a part of. :) -dman84
I don't have an opinion on this bug, and I won't mind if it gets WONTFIXed. I'm here to say that Mozilla can and must extend standards sometimes (ECMA-262 Edition 3, the JS standard, explicitly allows for such extensions). Design by committee and _de jure_ standardization do not innovate often or well. There is nothing wrong with experimentation by implementors, so long as it's controlled (and doesn't escape the lab and wreak havoc in the wild -- the case could be made that adding target="_tab" would lead to confusion on the web, so again, I'm not saying that *this extension* is ok -- only that Mozilla code can and should extend standards in thoughtful ways). /be
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0.1
Web page authors should not be able to subject users to MDI unless the user chooses to have webpage-opened windows go to tabs using the pref from bug 103843. I think there's already a pref to make middle-clicking on links open the links in background tabs, so it wouldn't make any sense for web pages to have checkboxes altering the behavior of links (that's the job of user prefs, keyboard modifiers, and extra mouse buttons). *** This bug has been marked as a duplicate of 103843 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → DUPLICATE
I don't think that's a dup of 10384, if you want to mark it Invalid or Wontfix because implementing this feature would be against the standards fine. But its not a user preference issue, my request has to do with the developer, a way to take advantage of the tab feature in the design of a website...
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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
Um... target="_tab" would directly violate the HTML spec. It's not just an extension, it's explicitly prohibited. All targets starting with "_" are reserved and may not be used except the ones defined in the spec. I'd just like to repeat that the page should just be able to request a new viewing area. The _user_ should choose where that viewing area appears. If this functionality is added there had better be an option for "open new tab in new window" and I would urge that it be on by default.... Please just wontfix this....
wontfix; feature creep, standards foo, and simple lack of resources
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → WONTFIX
Good points I see here. One approach would be to open the new page in a tab .. if the browser is the Tabbed Mode. So for example if you already selected the tabbed mode, then the _top would open a new tab.
*** Bug 116434 has been marked as a duplicate of this bug. ***
If we _do_ implement this, those prefs had better be _off_ by default. We should not _ever_ accidentally open new tabs unless the user has explicitly set the tabbrowser preferences accordingly, in my opinion.
I agree with the coment #26 Opera uses <a href="url" rel="sidebar"> to add an url to the sidebar, maybe a <a href="url" rel="tab"> or something similar is a way to go...
Status: RESOLVED → VERIFIED
*** Bug 126914 has been marked as a duplicate of this bug. ***
*** Bug 152358 has been marked as a duplicate of this bug. ***
*** Bug 155087 has been marked as a duplicate of this bug. ***
*** Bug 160780 has been marked as a duplicate of this bug. ***
[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.
Severity: normal → enhancement
*** Bug 186330 has been marked as a duplicate of this bug. ***
I voted for this because I wanted functionality which I later found in Safari. Safari has a feature in the bookmark window called "Open In Tabs" which allows me to go to folder "Morning Patrol" and click on the last entry "Open In Tabs" and then all the sites I visit when I first log in pop up in different tabs. There doesn't appear to be any code in the bookmarks file to enable this feature, but this can't be the only useful embodiment of the code. I sincerely hope the Mozilla team will reconsider this bug.
Chrys, the feature you are looking for in Mozilla is "bookmark groups" (open a set of tabs, then go to the Bookmarks menu and select "Bookmark this group of tabs"; in Firebird this has a slightly different UI, which may be more like Safari's). _This_ bug is about allowing web designers to force pages to open in tabs. Which is why it's marked WONTFIX -- the user should decide where they want pages opened, not the web designer.
The web designer has the ability to open new windows as a historical accident, more or less. This ability is misused more often than not. And blocking it is a losing battle, as you will discover if you look over the bugs that cover various ways sites use to evade popup blocking.... The choice of using tabs or windows is up to the user right now, and there are no good reasons I've seen for not keeping it that way. The designer gets to express a wish to have some content in a new viewing area; the user gets to decide whether this viewing area is a new window, new tab, or new desktop background.
*** Bug 222754 has been marked as a duplicate of this bug. ***
Sorry about the dupe, but here are my thoughts: Using tab="1" and tab="2" as specified in Bug 222754 would be a very simple solution (that would give web designers more capabilities than was originally specified), and would still allow the links to function properly if there were no tabs. A simple "Allow HTML to open links in tabs" option in the preferences would eliminate the concern of designers opening in new tabs when the user doesn't want that. What other arguments are there against this?
>Using tab="1" and tab="2" and destroy whatever the user had opened in that tab?
The number idea isn't working for me. Why not use names as is done with windows. That makes better sense. Something like rel="tab" target="newtabname".
> What other arguments are there against this? The same argument that's given elsewhere in this bug. The only argument against this suggestion, in fact. THE USER MAY NEVER WANT TO SEE A FRIGGIN' TAB.
>The same argument that's given elsewhere in this bug. The only argument >against this suggestion, in fact. THE USER MAY NEVER WANT TO SEE A FRIGGIN' >TAB. As others and myself have suggested, there could be an option for it in the preferences - if you have an option to allow it, that is off by default, everyone is happy. >and destroy whatever the user had opened in that tab? It would be opening in a "new" tab, and it wouldn't effect any existing tabs unless there was a specified target tab. >The number idea isn't working for me. Why not use names as is done with >windows. That makes better sense. Something like rel="tab" target="newtabname". What I was trying to is find a way for it to work where the following could be done: You can open a link in a new tab. You can open the link in a target tab. Those would both work You can open the link in the targetwindow, and if the window is already open it opens in a new tab in that window. Having just rel="tab" wouldn't be able to do the last one, unless you added rel="wtab" as well (wtab = target window tab). That would do the exact same thing as I suggested before, I just used tab="1" and tab="2" for lack of a better name.
What gets me about the arguments offered here is the double standard. It's OK for a new window to open when a user clicks on a link (target="_blank"), but it's not OK for a new tab (say, target="_tab"). The prevailing argument that I've seen is that some users might not want to see a tab, ever. Well, I don't ever want to see a new window, but what are you guys doing to help me? I know I'm not in the minority when I say that I don't ever want to see a new window. If this won't get fixed, why don't we kill off the "_blank" behavior as well?
Perhaps you missed the point of the arguments. The argument is that target="_blank" should open a new tab if the user so desires (and this seems to be what you desire). And sites should just use that, and users get to choose what sort of new page is opened -- window or tab. The preference to get tabs to open for target="_blank" is covered by a different bug.
The preference to get tabs to open for target="_blank" is covered by bug 103843 or bug 105547. (bz, don't you have "collect buglinks" on your bookmarks toolbar?)
So what about the case that I mentioned, where the user might want a script in a bookmark to open a new tab? Is my previous comment, #41 being ignored because you all think that should be covered by a different bug, or are you all just ignoring it because you feel like ignoring it? Dave A.
C'mon, no standards body is going to codify _tab, and we're not going to add it just for the works-in-Mozilla-only content authors. Again, the page author can't specify window vs. tab, just "_blank" -- which could mean either, if we fix that other bug; it often means neither, for me (popup blocking). /be
Dave Anderson, that would need to be solved within Mozilla (probably by totally changing how bookmarklets work). Feel free to file a bug on rewriting that.
Dave: or you could wait until bug 138198 is fixed, and then middle-click the bookmarklet instead of left-clicking it.
AH-HEM! The main topic of question has been strayed away. I want to do this: if(in-a-form.option('userwantstabs')) window.openTab('thisURL'); What is so hard about it?
> if(in-a-form.option('userwantstabs')) window.openTab('thisURL'); > > What is so hard about it? The fact that we don't trust you to do that if check. We would rather you use window.open() and we map that to something like openTab() ourselves if the user so desires (and that way it will work on all sites). But again, that latter part is not covered by this bug.
> if(in-a-form.option('userwantstabs')) window.openTab('thisURL'); If this were implemented, it should be an option to window.open ("tab", maybe). But the reasons this bug was WONTFIXed were feature creep, standards foo, lack of resources -- and especially, the ability of web content to abuse the user. You cite a nice case, where the content gives the user a tab only when the user has said he wants one. Even ignoring the feature creep, standards, and resource problems, the above could be easily abused unless we add a separate pref that stops window.open(..."tab"). If we had such a pref, then what should happen in the common case where the pref defaults to "disable tab opening"? Open a new window instead of a tab? That's clearly wrong in the case where the user has clicked a checkbox on the page saying "userwantstabs". Do nothing? Also bad. You see the problem. We can't give your "good" content this sharp tool without giving it to all content. If (to prevent bad content from abusing users) we pref tab-opening off by default, then you'll have to get your users to flip the pref *and* to click the "userwantstabs" checkbox (or whatever it is you had in mind). You tell me what's so hard about that. /be
I can't see that argument as being valid, since there's already a pref which prevents popups on certian situations. Extend that to tabs -- there should *never* be a window or tab opening inside document.onLoad() or a timed event handler -- and much of the abuse you say goes away. Everything else in the argument would require me ranting about other features which "creeped" in and nested, making feeping creatures.
*** Bug 226105 has been marked as a duplicate of this bug. ***
That's not a standard, it's a proposal. And it's being argued against quite a bit. I wouldn't bet on it staying in its current form...
From <http://blogs.msdn.com/ie/archive/2005/05/26/422103.aspx> (IEBlog) : >Our philosophy for tabbed browsing is to keep the user in control of the >experience. Tabs are on by default in IE7 Beta 1, but for those that do not want >to use them they shouldn't be intrusive and there's a setting to turn them off >and reclaim the screen real estate if desired. > >Regarding script, there is no "target='_tab'" feature or any direct access to >tabs from script beyond what is available with multiple windows today. So, even Exploder isn't going to implement it ...
I don't know why this bug has not been rectified? It all seems quite logical to me! 1) You can't limit such an important feature. 2) All issues can be addressed by an additional option in the preferences (which is turned off by default). In other words 3 options in Preferences - a) Never Use Tabs, b) Always Use Tabs, and the important one - c) Use Tabs If Requested. It couldn't be any simpler, and I just can't believe how such a simple request, has grown out of all proportion, with lack of brains on both sides of the argument - you all obviously live in a Monty Python universe. I have a home page, where I have all my favourite links, which to me is much more sensible than always using bookmarks, but since changing to Mozilla (which I mostly love), I have been frustrated by the inability to hard code my links to open in tabs (i.e. target=_tab), I am sick to death of always right-clicking, and no I don't want everything to open in tabs. I would say that I use tabs about 50% of the time. To explain this (should be bleedin' obvious), I don't want to have to keep on closing tabs, when I don't need to (which happens if everything is opened in tabs - by the way does anyone have their preferences set to always open tabs ... I didn't think so?), I like to open new links in the current window/tab, when I have finished with it (this saves on a lot of extra closing/clicking). TheSaint
I've been saying that all along -- add window.openTab(), and give the users a choice if Gecko wants to open it or not. YES I know if you open it, there's potential for abuse -- that's why you extend the popup blocker to kill unwanted background tabs in the same fashion as we do popup windows. Right now, NOBODY, not even USERS and DEVELOPERS, is getting any choice, and my website isn't getting done because of all this bickering.
> This is a usability feature for an enterprise application Feel free to use signed scripts that request expanded privileges. At that point you can do whatever you want in your app, _if_ the user grants those privileges.
You need to log in before you can comment on or make changes to this bug.