Closed Bug 103843 Opened 23 years ago Closed 19 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 → 19 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: