Closed Bug 105409 Opened 23 years ago Closed 23 years ago

[rfe] window.openTab() and <a href="url" target="_tab">

Categories

(SeaMonkey :: Tabbed Browser, enhancement)

Product:
SeaMonkey
Component:
Tabbed Browser
Platform:
x86
Windows 2000
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX
Milestone:
mozilla1.0.1

People

(Reporter: fabricio, Assigned: hyatt)

References

Details

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
Closed: 23 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 → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
"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)" ;)



Isn't this sort of opposed to Mozilla's standards compliance? The tabbed browser
is great, don't get me wrong, but isn't adding JavaScript and TARGET= control of
it basically the same as every other non-standard extension to HTML? 

Developers should be able to open new windows, yes. And users should be able to
say "New windows should really be new tabs." But until "openTab()" is part of
some sort of w3c spec, we shouldn't support it any more than we support any
other browser's nifty non-standard features.
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.

Maybe adding a new parameter to the open method is not the best solution, since
it would require changes in the javascript, I think that create a new object,
tabbar, just like they did for the sidebar could be the way.

Then to open a link in a new tab we would do:
window.tabbar.addTab(url)

And if we want to open in a new tab only if the user have a browser that support
tabs we should do just like we do with sidebar tabs today:

if ((typeof window.tabbar == "object") && (typeof window.tabbar.addTab ==
"function")){
   window.addTab("http://www.mamata.com.br/");
}else{
   document.location.href = "http://www.mamata.com.br";
}

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.


Using javascript and browser sniffing is a kludge. Set a preference for this
behaviour and allow either a meta tag or window.open feature string to denote a
preference for opening in a tab. Perhpas this is too big a deal and this feature
should be debated more in the newsgroups for now. Tabs are magnificent but
authoring with tabs is not worth getting in the way of any 1.0 work.
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
Closed: 23 years ago → 23 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
Closed: 23 years ago → 23 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. ***
Ok, I understand why we can't really use _tab (reserver by the HTML spec), but I
do think the ability to have standard-type HTML links that open in a new tab
would be a good thing. It's just like _blank in a lot of ways, and can be
prevented in JavaScript (if we wanted to) the same way _blank from JavaScript is
(Script settings, under Advanced on prefs).

But, however it is done, I would really like to see a 'open in new tab'-type
link, without the user having to navigate a context menu, set special prefs, or
having to resort to JavaScript.
I actually would like it to have a Javascript method, plus a userpref which says
"Allow scripts to open new tabs" along with "Allow scripts to open new
unrequested tabs."

There's sufficent intrest.  Request reopen/new on this RFE, all platforms, but
for a far future milestone (Mozilla 2?)
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...
v
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.
WHOA WHOA WHOA WHOA!  Doesn't the web designer already have tools to open new
windows in Javascript?  Doesn't the web user already have tools to block such
opening of new windows now?

What is preventing the Mozila group from extending BOTH to cover tabs?  Or
should we all just yank down the CVS version, extend it ourselves, and shove the
patches here?
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.
It would be really nice to see some sort of solution to this... I've voted for
this bug because I see very good possibilities for such a feature. Here is an
example where I really want to open a new tab and I am the user entering the
code, so I KNOW I want it to behave this way:

This is code supplied by Google; it is entered as one continuous line as the
destination URL for a bookmark, for example on the personal toolbar. I've broken
it up a bit here for readability. The way this works is, the user selects some
text on a web page, then clicks this bookmark and a Google search is performed
with the selected text used as a search term. If no text is selected a dialog
opens and prompts for keywords.

javascript:q=document.getSelection(); \
for(i=0;i<frames.length;i++){ \
q=frames[i].document.getSelection(); \
if(q)break; \
} \
if(!q)void(q=prompt('Keywords:','')); \
if(q)location.href='http://www.google.com/search?client=googlet&q='+escape(q)

Now, I REALLY don't want the page I'm viewing to disappear, I want the Google
search to open in a new tab. There seems to be no way to do this. BTW, I don't
care if the new tab loads on top or loads in the background, but I suppose that
if this gets implemented it would be easy enough to add a control for this
behavior at the same time.(Isn't there already a control for this?)

Now a lot of you may be tired of discussing this bug, but please stay with me
here...

There are a LOT of potential uses for this, like babelfish, stock quotes,
mapquest, other search engines.... limited only by the users imagination. I see
a couple of good arguments against this functionality, and a lot of good
arguments for it.

One of the strongest argument I see for it is in Comment #40:

"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."

In this case, I _AM_ the user, but I _CAN'T_ control this. (Sorry if you didn't
mean it the way I do, Boris)

So, here's a thought... I don't know how feasible this is, but it seems to
address most if not all of the reservations expressed above:

Why not set this up as a function that only works in bookmarks? That way it
can't be abused by page designers. It won't break the spec because it can't work
in a page. 

Another possibility, though I cringe at the thought of major code churn in
bookmark handling, would be to allow users to flag bookmarks to open their link
in the current tab or a new one. The capability of setting this for all
bookmarks is not granular enough IMO.

Adding some sort of property to the bookmarks file sounds risky to me. OTOH, a
function that works only in bookmarks would allow users to put a simple function
in the particular bookmarks that they want to open in new tabs... only those
users who want to bad enough to go find out how it's done would be using the
feature so it's unlikely to affect the average user... they would never see a
difference.

Even if the above suggestions are unworkable, I think that it would be a VERY
useful feature even if it were available in web pages. I don't see as much need
for the functionality to work there since I habitually middle-click to open in a
new tab anyway. Mozilla seems to be quite good at blocking unrequested pop-ups
while allowing popups that I click on to work... Maybe some of this code can be
re-used or re-purposed to prevent abuse of the new function. If you start off
implementing it with abuse prevention in mind it will likely never become a problem.
*** 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. ***
(In reply to comment #9)
> Isn't this sort of opposed to Mozilla's standards compliance? The tabbed browser
> is great, don't get me wrong, but isn't adding JavaScript and TARGET= control of
> it basically the same as every other non-standard extension to HTML? 
> 
> Developers should be able to open new windows, yes. And users should be able to
> say "New windows should really be new tabs." But until "openTab()" is part of
> some sort of w3c spec, we shouldn't support it any more than we support any
> other browser's nifty non-standard features.

I think there is an standard...

http://www.w3.org/TR/2004/WD-css3-hyperlinks-20040224/#target-new
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.
I want to add another point of view: Since Flash Player 7 you were able to create custom Context Menues. Same goes for JavaScript and meanwhile almost all browser support it. I don't see any way for a developer of the Flash plugin (or any other of those plugins) to directly call a new tab via browser API because there is no standard defined for this. And furthermore everybody needs to wait until the new version of each browser AND the new plugin is spread (which takes years).

But(!) all those plugins allow direct JavaScript access so it would be easy for the end developer to just call the matching javascript method and its done - of course on request. For the Flash-case this would allow developers to create a far better user expirience.

I for myself think that the window.open (newtab=yes) would be the best approach because I don't see anything breaking (if you use the initial "target" attribute thats not the case and openTab is also non-standard by not defined). 

If I can identify this properly then the only drawback for this is to have a lack in user control, which could be very well done within the javascript access settings. But I vote for not deactivating it by default else the Flash case would be completly pointless for the masses.
Tabs are a great usability addition.
They make the internet experience nicer.

Multiple windows were also a great feature but got hijacked by <you know who>.
So popup killers became an usability feature (eventhough it's a lost battle) that is a must-have to crawl the internet, nicely.

The fact that good usability GUIs are not standards is not a sufficient reason not to deploy them.
Standardisation could and should come after.

The point of decision should come from experience.
Windows and tabs are good, but could be used against the user.
How do a popup killer work ?
Seems that when the user doesn't request a content (read click on a link), the popup is seen as not desirable.

So my question is : what prevent the use of the same behavior in conjonction with the already in place popup killer ? 
- If the user wants it, click on it.
- What happen when he'll click ? Insert message in the status bar to tell him it will open a new tab.
- unwanted tab opening from script ? Keep the user pref scheme.
Seeing that, why not adding this as a new mozilla add-on, to make the user experience greater.

Now, when it comes of javascript API, none of the choices will be standard, because tabs are not accepted as standards GUIs.
Nevertheless, the window.open (newtab=yes) is pretty clever, in terms of API extension, since this last parameter is already a *long and sompetimes funny* string.

On a side note, I folllow Martin's post, because it obviously could have make flash more usable, eventhough mots of don't even care. Is Flash standard or a de facto standard ?

I have a specific commercial need for multiple tabs. This is a usability feature for an enterprise application administered via a web interface and I need to keep several pages in sync. Please get this feature (or bug) fixed soon :o) 

If you're worried about misuse, I agree with the previous posters that popup blocking, either blacklist (allow all, unless they appear in my list) or whitelist (allow nothing, unless they appear in my list) is the natural way to handle it.

ps. can I add my vote for "window.open (newtab=yes)"
pps I take it normal JavaScript could be used to modify (refresh/update/etc) the content of another tab (ie a function on tab-A could be used to force a refresh or new 'src' on tab-B)?
> 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.
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.