Closed Bug 172962 Opened 22 years ago Closed 20 years ago

Options for where to open URLs from other applications (reuse tab, new tab, new window)

Categories

(Firefox :: General, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
Firefox1.0

People

(Reporter: dueydotnet, Assigned: danm.moz)

References

Details

(Keywords: conversion, fixed-aviary1.0)

Attachments

(9 files, 9 obsolete files)

1.17 KB, patch
jst
: review+
Details | Diff | Splinter Review
19.04 KB, patch
jst
: review+
peterv
: superreview+
Details | Diff | Splinter Review
5.36 KB, patch
jst
: review+
peterv
: superreview+
Details | Diff | Splinter Review
6.74 KB, patch
bryner
: review+
Details | Diff | Splinter Review
5.03 KB, patch
bryner
: review+
Details | Diff | Splinter Review
7.35 KB, patch
mikepinkerton
: review+
Details | Diff | Splinter Review
6.97 KB, patch
blizzard
: review+
bryner
: superreview+
Details | Diff | Splinter Review
2.74 KB, patch
bzbarsky
: review+
Details | Diff | Splinter Review
20.18 KB, image/png
Details
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021006 Phoenix/0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021006 Phoenix/0.3

Tbis is a dupe of http://bugzilla.mozilla.org/show_bug.cgi?id=75138 (for
Mozilla).  There's a great discussion of it over there.  However, that RFE has
been listed for over a year now and is still marked for "future".

I think this feature would be important.  I, myself, prefer links to open new
windows.  Others would prefer them to use an existing window.  Now that you can
also browse with tabs, other people might like a combination of the two (open a
new tab in an existing window).

Right now it's pretty much random for me.  Some applications open links in a new
window while others seem to always use the top most window.  However, I think
it's important that opening new links be consitant.  I can't get all of my
applications to do the same thing, so it's logical that I should be able to set
my browser to act only one way.

I would like to open up this enhancement for Phoenix since (I think) the
developers of Phoenix can add features independant of Mozilla.  However, I'll
understand it if you feel this isn't that important.  At least you will have
considered it.

Reproducible: Always

Steps to Reproduce:
Changing summary.
Summary: [RFE} add an option to determine how other applications can open new windows in Phoenix → [RFE] Option to determine how other applications open new windows
Maybe later. Hyatt expressed interest. Confirming. 
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: [RFE] Option to determine how other applications open new windows → Option to determine how other applications open new windows
*** Bug 174928 has been marked as a duplicate of this bug. ***
*** Bug 173978 has been marked as a duplicate of this bug. ***
Related Mozilla bugs:
bug  35578 Mailnews should open http/ftp links in new browser window by default
bug  75138 pref to open links from other apps/components in a new window
bug  90992 link in mail msg should open in last-active browser window, not oldest
bug 121969 URL requested by other apps should open new tab, not window
Target Milestone: --- → Phoenix0.7
I think this bug is important for IE compatability, as its one of the noticable
IE features that is not in Phoenix and is frequently annoying for those IE uses
that *don't* select the "reuse windows for launching shortcuts" option (which I
think is selected by default.

I would like to see (as mentioned in the related Mozilla bug report):

o Open a new window for shortcut
o Open a new tab for shortcut
o Reuse selected tab/window for shortcut

The last text makes the behavior of the shortcut clear (which is sometimes a
complaint with people).
This is one of the few features that are missing from phoenix that I miss from
when I was still using IE!  The biggest problem I have with tabs/windows being
reused for launching shortcuts, is that it can cause you to lose whatever you
might have been working on in that tab/window.  It's happened to me far to many
times.

This bug gets my vote.  Any chance we can get this sooner than 0.7, or do we
have to wait for them to handle it on Mozilla and pick up that fix?
I actually created a bugznilla account to vote for this bug. I switched my g/f
to Phoenix after we both became frustrated with the latest IE. She loves it,
except for the fact that it reuses windows. Frequently, she'll be posting to a
message baord, and I'll AIM her a URL to include. She'll click the link, which
will obliterate her half-written post. Since the message board software
helpfully suggests that the posting URL shouln't be cached, it's now gone forever. 

This bug is her *only* complaint with Phoenix. She is not a geek, she doesn't
care about open-source, and with the exception of this bug, she loves Phoenix.
A temporary work-around to stop URL's from using existing windows is to add this
line:

user_pref("advanced.system.supportDDEExec", false);

...to your user.js file (it might not exist, so create it, it belongs in your
profile directory where prefs.js is).  I'd recommend using user.js over prefs.js
because user.js is only read by Phoenix (not written) and overrides prefs.js
settings.
*** Bug 187190 has been marked as a duplicate of this bug. ***
*** Bug 188179 has been marked as a duplicate of this bug. ***
*** Bug 205426 has been marked as a duplicate of this bug. ***
The Tabbedbrowser Extension by Piro handles this.
I have a related issue.  When I start my browser, I want to do one of four things:  

1) The browser is not running.  I want to start the browser and open a blank 
   window.  I'd run the command:
       /usr/local/firebird/MozillaFirebird about:blank
   or just 
       /usr/local/firebird/MozillaFirebird
2) The browser is running, but I've forgotten that.  I want to pull up the 
   browser and open a blank tab, without destroying the already open tabs.
   I'd run the command:
       MozillaFirebird -remote "openurl(about:blank, new-tab)"
3) From another app (email client, whatever), I click on a URL and want it to 
   open in my browser, which is not alrerady running.
       /usr/local/firebird/MozillaFirebird $URL
4) Same thing, but my browser is already running.  I want:
       MozillaFirebird -remote "openurl($URL, new-tab)"

I wrote a script which accomplishes most of these tasks.  I called this script 
/usr/local/bin/firebird:

	#!/bin/sh
	 
	BROWSER=/usr/local/firebird/MozillaFirebird
	 
	LOCAL="about:blank";
	if [ $1 ] ; then LOCAL=$1 ; fi
	 
	$BROWSER -remote "openurl($LOCAL, new-tab)" &> /dev/null || \
	exec $BROWSER $LOCAL &
	
I use this command from the command line, from an icon in my Gnome panel, and 
the Gnome 'htmlview' command.

I suggest that you make this script, or something like it, part of the default
Firebird for linux install.
I checked out the latest version of the Tabbed Browser extension by Piro, and it
does, indeed, accomplish all of this -- no special shell scripts required  (:

the only problem is that it so far seems to only install under the nightly
release for win32, and attempting to install it under linux yielded no result: i
have some other arb extension installed, but this one refuses to actually
install (depsite providing a positive feedback on completion of its install
script). A real pity, because the Tabbed Browser Extension, which used to be
mildy useful, now provides all the functionality i was lacking from the browser
side of things in
phoenix^H^H^H^H^H^H^Hfirebird^H^H^H^H^H^H^Hmozilla-cut-down-browser-thingy.

I live in hope that one day the linux version will install the extension...
Regardless of the fact there's an extension available that does this, this is
really a function that should be handled directly by the browser itself.  It's
something that people should be able to configure out of the "box" without
having to hunt down and install extensions.

As far installing extensions in Linux, I reported bug 199866 a while ago about
having trouble with extensions in all Mozilla browsers, but it never went
anywhere, so it either got ignored, forgotten, or perhaps is invalid and I'm
just stupid.
the supportDDEExec = false trick no longer works as of 20030714 at least, going
back a few days as well. 

Related Mozilla bug <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=192286">here (192286)</a>

The workaround of deleting/renaming HKCR/http/shell/open/ddeexec works for me in
the meantime...
*** Bug 214501 has been marked as a duplicate of this bug. ***
Target Milestone: Firebird0.7 → Firebird0.8
*** Bug 218665 has been marked as a duplicate of this bug. ***
QA Contact: asa
*** Bug 222547 has been marked as a duplicate of this bug. ***
*** Bug 222504 has been marked as a duplicate of this bug. ***
*** Bug 222586 has been marked as a duplicate of this bug. ***
The line user_pref("advanced.system.supportDDEExec", false); placed in user.js
works fine in current builds. 

Might I ask the devs to simply include this line in all.js as an interim step?
For one thing, if the line is in all.js, then it will be available in
about:config where users can change the setting.
-> 0.9
Target Milestone: Firebird0.8 → Firebird0.9
*** Bug 234384 has been marked as a duplicate of this bug. ***
*** Bug 234759 has been marked as a duplicate of this bug. ***
*** Bug 235324 has been marked as a duplicate of this bug. ***
This needs to happen in the DDE stuff in toolkit/xre/nsNativeAppSupportWin.cpp
for windows... don't know about the other platforms. 
Target Milestone: Firefox0.9 → Firefox1.0beta
As most replies to my requests have been 'get tab browser extension' I would
just like to elaborate a little.

I should very much like to be able to have external links open in new tabs
(rather than windows) in Firefox on Mac OS X.  There are *no* tab browser
extensions compatible with OS X, thus replicating this behaviour (which is
present in Safari/Camino/OmniWeb/iCab) is near impossible.

I really think this should be part of some default options, especially as Ben
Goodger points out - Tab browser prefs muck around with Firefox's inner workings.
http://www.washingtonpost.com/wp-dyn/articles/A8165-2004Mar19_2.html

See the paragraph starting, "It will take at least a few more months for Firefox
to hit 1.0, and in that time I hope that this browser's crew of developers
addresses a few..."  The immediate next (and first overall in the article)
complaint is for this feature.
Keywords: conversion
Flags: blocking1.0?
Flags: blocking0.9?
Personally, I would really prefer that this not block 0.9.  It's been coming for
long enough, and there's enough work to do for extensions and updating... not
worth it in my very and always humble opinion.

However, I do think the current behaviour is unpredictable and annoying (without
changing advanced.system.supportDDEExec, that is...) - but that's just me.  I've
always felt that "stealing" windows is a horrible thing for any application to
do, because by and large you lose important information. (winzip, ie, etc.) 
But, some do not agree of course - maybe even most do not. (I'd love to see a
poll on this issue!)

I know there's work that should be done to standardize the way this works.  And
to make it so tabs work.  And yes, all that is very ENHANCEMENT material.  I
know that is essentially what the bug is about.  And there have been tons of
dupes, a decent number of votes, and some interest as well for the mozilla reason.

What I propose is that - whether this is fixed or not for 1.0 (which personally
I wouldn't mind if it isn't...) what would make a LOT of people happy is some
sort of interface for this:

user_pref("advanced.system.supportDDEExec", false);

Besides just about:config - it's a wonderful tool, but most of my clients would
get confused and close the window if they saw it.  If there could be a quick
option (just as a kludge to make people happy!) in Advanced -> Browsing, more
people would find this option.  At least so I think.  And that would make more
people happy.  That to me seems like almost a different bug, one that isn't just
a trivial/enhancement one.

But again, I see no reason to slow down releases for this.  If that option could
be added before 1.0 - just the DDEExec, it would make people a lot happier
without really that much hassle... and it would reduce support/duplicate-marking
work to a degree... and make Firefox look better, imho.

Personally, I believe that proper handling of this is something IE doesn't even
have to any degree; but advanced.system.supportDDEExec is something IE *does*
have in it's advanced options.

Just my cent and a half.  Probably shouldn't be posting this so few hours after
having my 7 (yes, I'm a freak of nature!) wisdom teeth pulled.... still feel
groggy from the anesthetic.

(sorry, this reply was caused by getting an email for a request for blocking
flags on the bug which I'm against... though again it's just my own opinion.)

Thanks for your time,
-[Unknown]
not a 0.9 blocker, not really a 1.0 blocker either.  It'd be nice to have, but 
making this work properly on Windows is really really nontrivial, 
unfortunately.  Remote scripts on *nix can use new-tab/new-window, but that's 
xremote
Flags: blocking1.0?
Flags: blocking1.0-
Flags: blocking0.9?
Flags: blocking0.9-
Implementation being non-trivial or not, many many many people will tell you
that this is a big issue for those migrating from IE, and thus for evangelism
and user adoption. I've seen LOTS of anectodal evidence (/., personal
experience) that first-time firefox users do not continue using the browser
after discovering this bug. 
Look, as I see it we have two options:
A) Keep the current setting which can result in data loss
B) Flip the user pref which makes links open in a new window. This does not
result in data loss

This does not seem like a hard decision to make.  What problem caused by option
B) could possibly trump data loss?
(In reply to comment #34)
> This does not seem like a hard decision to make.  What problem caused by option
> B) could possibly trump data loss?

I agree completely.  If it's as simple as changing a binary preference that
doesn't have the UI representation it should, that is obviously better than
potential data loss.

Who can re-enable blocking for 0.9 and (or, at least) 1.0?
Flags: blocking1.0-
Flags: blocking1.0+
Flags: blocking0.9-
Flags: blocking0.9+
(In reply to comment #35)
> Who can re-enable blocking for 0.9 and (or, at least) 1.0?

With all due respect, not you.  A Firefox developer already came around and
decided that this wasn't critical for 1.0, and as he's the primary Firefox
developer anyways, what he says, goes.  Please don't fiddle with the blocking
flags; they've been set that way for a reason.  (Of course, if you want to work
on programming this I'm sure Ben would be more than willing to consider any
patch you or anyone else makes.)

That said, I wonder whether the enormous effort is required to simply make each
link open in a new window as opposed to the current window/tab.  There's no
dataloss issues with that, though it is somewhat of an inconvenience.  Oh well,
I really shouldn't talk as I have no idea how easy/hard this is to code.
Flags: blocking1.0-
Flags: blocking1.0+
Flags: blocking0.9-
Flags: blocking0.9+
"I wonder whether the enormous effort is required to simply make each link open
in a new window as opposed to the current window/tab.  There's no dataloss
issues with that, though it is somewhat of an inconvenience.  Oh well, I really
shouldn't talk as I have no idea how easy/hard this is to code"

I can set this to function either way.  First, I had the pref
user_pref("advanced.system.supportDDEExec", false); 
in my user.js file.

Then, when I decided I wanted to open everything in a single window, I installed
the newest version of Tabbrowser preferences (0.5). Works with nary a problem.

I would like that line in my user.js file to be a checkbox in Options. I would
like Tabbrowser Preferences to be part of Options. 

Not difficult, now: someone else has already done the work.
advanced.system.supportDDEExec is flaky, but if someone wants to file a separate
bug on changing the default value, please do so/cc me on it.  This has always
been about a comprehensive solution to how a tabbed browser should behave.

also, I'm not the primary Firefox dev, that's ben, but while this would be nice
to have, based on the last time I mentioned this in conversation, it was made
pretty clear that we'd have to really delve into how tabbed browsing works to
make this work "right"  And said delving is not trivial/easy.
How FireFox behaves wrt loading URLs from other apps recently changed. URLs
loaded from other apps used to always open in the last active window, but with
todays branch build (and maybe some that are some number of days old too) they
open in a new window.

I find this change extremely annoying (and evidently others do too), and per a
discussiong with Ben, I'd like to see options for opening URLs loaded by
external apps in:

1) Last active window.
2) New tab in last active window
3) New window

Marking this blocking1.0+ per Ben's request.
Flags: blocking1.0- → blocking1.0+
Enjoy. 
Assignee: firefox → jst
Priority: -- → P3
Pardon my ignorance, but enjoy what?
(In reply to comment #41)
> Pardon my ignorance, but enjoy what?

Look at the bug activity and correlate it with Ben's comment time.  You'll
understand then.
Up until 0.8, Firefox opened links (such as from Thunderbird) into the same
window.  However, as of 0.9rc and 0.9final, it opens links in new windows, which
is kind of frustrating.  I would prefer it to open in the same window, or at
least to open in a new tab.  
Glad to see this made it onto the radar, and is finally blocking.  With this bug
and the four listed in Comment #5, we have almost 200 votes for this issue.

I finally tracked down the culprit in my user preferences; don't know how or
when it got set to a user-defined value, but there is a simple, boolean
preference to control this behavior:

browser.always_reuse_window

true > links from external applications will open in the frontmost window/tab.
false > opens a new window

Through Comment #5, I also found that Bug 75138 Comment #35 and Bug 121969
Comment #16 mention this hidden preference.  Those comments claim this only
works on the Mac, so YMMV.  If only the preference itself had been posted
before, it would have saved us lowly users a lot of headaches and hunting.

Now all we need is a GUI control for this preference.  And unification of the
myriad "open external links in this way" bugs.

Also, shouldn't this be VERIFIED or something?
*** Bug 248504 has been marked as a duplicate of this bug. ***
*** Bug 248449 has been marked as a duplicate of this bug. ***
Summary: Option to determine how other applications open new windows → Options for where to open URLs from other applications (reuse tab, new tab, new window)
In case this should matter, Tabbrowser Preferences has a relatively simple
function called TBP_Startup() which directly implements the logic, albeit in
JavaScript, that the changed summary elucidates.

The relevant part of the function is as follows:

   switch (targetPref) {
      case 1 : {
	 TBP_Focus(topWin);
	 topWin.window.openNewTabWith(url, null, null, true);
	 window.close(); // Need to fix JS error generated here
	 return;
      }
      case 2 : {
	 TBP_Focus(topWin);
	 topWin.window.loadURI(url);
	 window.close(); // Need to fix JS error generated here
	 return;
      }
      case 3 : {
	 TBP_Focus(topWin);
	 topWin.window._content.addTab(url);
	 window.close(); // Need to fix JS error generated here
	 return;
      }
   }

0: New Window (default), 1: New Tab, 2: Current Browser, 3: New Tab, Unfocused.

Is this what the aim of this bug is meant to be?
Assignee: jst → danm.moz
Is this a difficult bug to address?  Out of curiosity, why has this bug been
open for so long, with so many duplicates, so many votes and so many comments? 
Is it a difficult engineering prospect in this case to enable the user to make
the browser behave as they wish?  If so, why?  It seems like it should be a
relatively straightforward change.
Flags: blocking-aviary1.0RC1+
Flags: blocking-aviary1.0RC1+ → blocking-aviary1.0RC1-
What is the potential l10n impact of this bug? Is it a hidden pref or does it
need UI?
Whiteboard: l10n impact unknown
comment 49: the current owner really hasn't taken this bug to heart yet, because:
comment 40: busy with more important bug; not enjoying just yet. Holy crap! 94
votes! I promise to look, but not tomorrow-immediately. Someone else could take
this if there's interest.
comment 50: good question.It sounds like there already is a UI-less preference
(comment 44) on one platform that we could adopt elsewhere. But with what seems
to be such a highly visible bug, it does kind of want a localized string,
perhaps under Tools Menu -> Options -> Web Features -> Advanced.
Any changes that affect l10n need to be landed by Aug. 25 (next Wednesday). If
we're not sure we want to do this bug, we can still land the localized strings
before the l10n freeze, and get the code reviewed later.
Flags: blocking-aviary1.0PR- → blocking-aviary1.0PR+
Whiteboard: l10n impact unknown → affects l10n
*** Bug 256720 has been marked as a duplicate of this bug. ***
Still I'm not especially looking at this bug. However since today is UI Day,
I'm trying to figure out what localizable text we may need. I've combined this
bug, bug 75138, and bug 121969 to come up with a proposed UI. I'm thinking of
taking a few lines out of the "Block Popup Windows" list in Tools Menu ->
Options -> Web Features to make space, and adding these +ed lines:


  |							       |
  | Add Site   Remove Site   Remove All Sites		       |
+ |							       |
+ | [ ] Open URL from other app in new window | More Options | |
+ |							       |
  | [ ] Enable Java					       |
  | [ ] Enable JavaScript		      | Advanced |     |

| More Options | opens a not-so-little subdialog that goes

| Window Reuse Options						     |
| --------------------						     |
|				 New window   New tab	Current tab  |
| Open URL from other app in	    ( ) 	( )	   ( )	     |
| Open links in webpage in	    ( ) 	( )	   ( )	     |
| Open new windows in		    ( ) 	( )	   ( )	     |
|								     |
|				       | OK |	| Cancel |	     |

Note that the main option in the Web Features dialog is the same as the top
left option in the subdialog. Also note that "Open new windows in" is a
combination of two of Sören's suggestions from bug 121969 comment 9.

I think this smacks of ridiculous overkill. I don't promise to implement the
More Options dialog at all. But I think we at least have all the strings we
could want. With that, here's a patch for Firefox 1.0 l10n purposes.
"Window Reuse Options" is _precisely_ what I want!
(I want everything to open a new tab - 
see also http://bugzilla.mozilla.org/show_bug.cgi?id=18808)
Since this usually relates to "tabbed browsing," I propose a section in the
Tabbed Browsing prefs under "Advanced" like so:

Links sent from other applications should open in: 
 (*) a new window
 ( ) a new tab in the most recent window
 ( ) the current tab/window

[x] Force links that open new windows to open in:
     (*) the same tab/window as the link
     ( ) a new tab

If we expose this feature I think this is probably the best way to do it. I've
not heard the case made for opening of any link (untargeted) ... i.e. regular <a
href="foo.html"> ... opening all of those in new tabs/windows would be really
weird. The UI above covers (I think) the most common use cases. What do people
think?
(In reply to comment #56)
> Links sent from other applications should open in: 
>  (*) a new window
>  ( ) a new tab in the most recent window
>  ( ) the current tab/window

I think the title string is a little clunky, but I'm having trouble creating one
that's any better.  As for the options, the use of "recent" and "current" in the
last two when describing the window is inconsistent; it'd be best if you always
use one or the other.

> [x] Force links that open new windows to open in:
>      (*) the same tab/window as the link
>      ( ) a new tab
> 
> If we expose this feature I think this is probably the best way to do it. I've
> not heard the case made for opening of any link (untargeted) ... i.e. regular
> <a href="foo.html"> ... opening all of those in new tabs/windows would be
> really weird. The UI above covers (I think) the most common use cases. What do
> people think?

I think this is exactly what everyone's wanted; anything beyond should IMO be
TBE-land.  I don't believe there are any other situations that would strictly
fit the concept of "Single Window Mode."

For purposes of Help documentation for these features, I assume this will go
into the Advanced panel, Browsing section.  Can you clarify exactly where in
this section these prefs would go?  Another option (I think a better one) would
be to create a Tabbed Browsing section, move "Hide the tab bar..." and "Select
new tabs..." prefs to it, move the image resize pref to Browsing, and dele
Multimedia, pretty much as below:

[Accessibility]
 ...
[Browsing]
 [x] Resize large images to fit in the browser window
 [ ] Use autoscrolling
 [ ] Use smooth scrolling

[Tabbed Browsing]
 Links sent from other applications should open in: 
  (*) a new window
  ( ) a new tab in the most recent window
  ( ) the current tab/window
 [x] Force links that open new windows to open in:
      (*) the same tab/window as the link
      ( ) a new tab
 [x] Hide the tab bar when only one web site is open
 [ ] Select new tabs opened from links

[Software Update]
 ...

No matter how it's set up in the UI, tho, it will need to be documented in Help,
and without a clear layout of exactly how it'll be done, we can't do that in
time for the l10n freeze.  (Because it sounds like the feature won't actually be
in 1.0PR, I'd guess we'll probably just add the info but <!-- --> comment it out
so that l10n teams know what text will be present there in 1.0.)
(In reply to comment #57)
> (In reply to comment #56)
> > Links sent from other applications should open in: 
> >  (*) a new window
> >  ( ) a new tab in the most recent window
> >  ( ) the current tab/window
> 
> I think the title string is a little clunky, but I'm having trouble creating one
> that's any better. 

old:
> Links sent from other applications should open in:

new:
> Open links from other applications in:

:-)
Blocks: 75138
Blocks: 99945
Depends on: 257011
comment #58 has the wording pretty much spot on in my opinion. I think this is
the most intuitive.
I like how comment 57 suggests the fix along with the wording revisement from 58
*** Bug 257010 has been marked as a duplicate of this bug. ***
Good points, Jeff. I was operating under the assumption there was a tabbed
browsing section, I hadn't checked. I can create the strings for one, should we
want to add it, such as in your example. I'll add the strings for all of this
with revised text by 8/28. 
Whiteboard: affects l10n → affects l10n, ETA: 8/28 for strings.
(In reply to comment #62)
> Good points, Jeff. I was operating under the assumption there was a tabbed
> browsing section, I hadn't checked. I can create the strings for one, should we
> want to add it, such as in your example. I'll add the strings for all of this
> with revised text by 8/28. 

8/30: Ready?

;-)
I'm very busy with EM bugs right now... can someone whip up a patch to add these
strings to pref-advanced.dtd? 

Tabbed Browsing
Open links from other applications in:
a new window
a new tab in the most recent window
the most recent tab/window
Force links that open new windows to open in:
the same tab/window as the link
a new tab

(each line is a separate entity)
This should be a really easy patch to throw together quickly. Do so and I'll
review and land it. 
Keywords: helpwanted
Attached patch the stringsSplinter Review
per last comment.
Attachment #157454 - Flags: review?(bugs)
Attachment #157454 - Flags: approval-aviary?
thanks mano.
Whiteboard: affects l10n, ETA: 8/28 for strings. → [have patch] affects l10n - ready for review
Whiteboard: [have patch] affects l10n - ready for review → [have patch] affects l10n - ready for review ben
*** Bug 248449 has been marked as a duplicate of this bug. ***
Comment on attachment 157454 [details] [diff] [review]
the strings

r=jst to take some load off of Ben's shoulders.
Attachment #157454 - Flags: review?(bugs) → review+
Comment on attachment 157454 [details] [diff] [review]
the strings

a=asa
Attachment #157454 - Flags: approval-aviary? → approval-aviary+
Patch landed on the aviary branch.
Keywords: fixed-aviary1.0
Whiteboard: [have patch] affects l10n - ready for review ben → [have patch] affects l10n - review, waiting for checkin ben
Keywords: fixed-aviary1.0
Whiteboard: [have patch] affects l10n - review, waiting for checkin ben → l10n changes landed on aviary branch
Strings have landed, the remainder is now - for PR. 
Flags: blocking-aviary1.0PR+ → blocking-aviary1.0PR-
I'm actually looking at this. Expect an implementation patch soonish.
Status: NEW → ASSIGNED
I'm not in the CC-list so why am I still getting mails from this bug??? Get me
off please!
You voted for this bug.  Remove your vote or (I think) change your preferences
to get bugzilla to stop emailing you.
*** Bug 257254 has been marked as a duplicate of this bug. ***
any updates on this? its been about 9 days since Dan M posted about him creating
an implementation patch soonish. I'm hoping to see this in 1.0PR
*Developers, please ignore this message*


(In reply to comment #76)
> any updates on this? its been about 9 days since Dan M posted about him
> creating an implementation patch soonish. I'm hoping to see this in 1.0PR

Please, people!  Give him time!  "Soonish" could mean a lot of things; the only
thing we know it means is at least the requisite review (and rereview, &c. as
necessary) period before Firefox 1.0.

First, Ben only wanted strings in for this for 1.0PR so that localizers could do
this right for other languages for 1.0.  Second, he minused it for 1.0PR after
said strings were checked into source.  Ergo, it will *not* be in 1.0PR no
matter how much you wish it.  Third, as has been posted many times in Bugzilla
in both this bug and bug 227241, these problems aren't simple to fix.  It'll
take time.  Even if jst worked non-stop on this one feature, he might or might
not have it done in nine days.  He's been doing other things, too, and those
other things may be more important right now because this feature has been
pushed to 1.0.  It's all about priorities, and right now short-term problems for
1.0PR will be higher priority than long-term 1.0 problems.  Fourth, please
remember that this bug, which originally only covered how applications open
windows, has been morphed by Ben to include bug 227241.  These two bugs command
over 180 votes right now.  That's an incredible number, and we shouldn't waste
time with extraneous comments.

Fifth, every time someone nags, that's less time that jst could be working on
the fix.  Leave him alone until he's done, or risk having this *enhancement*
(remember -- 0.9 was theoretically feature-complete?  the new features that have
gotten in have done so solely through high-level developer support) be pushed to
After Firefox 1.0.

It's your choice:  Nag and watch the patch come when it comes, nag and watch it
come later than it would have otherwise, nag and watch the patch be pushed to
after 1.0, or stay quiet and wait anxiously ;-).

I know which option has the greatest chance of getting this bug fixed promptly.
 I also know which options have absolutely no chance of getting this bug closer
to being fixed.  I hope you (now if you didn't before) know too.

(If any person here has a response to this, please respond privately.  Then
you're not wasting everyone else's time.)
Aviary branch patch: Implements the ability to open external links and (anchor)
targets* in a current window, new window, or new tab, configurable using prefs.
Note the patch can't exactly be applied without modification. It adds a new
file and it assumes (trunk) attachment 149457 [details] [diff] [review] from bug 242237 has been ported
to the branch (with a name change from DOMWindowAccess to DOMWindowUtils, as
discussed in that bug).

* - anchor targets were discussed earlier in this bug. I expect the groundwork
laid here will help with bug 227241.
Attached patch finish implementation of pref UI (obsolete) — Splinter Review
Note the UI is turned on only in Windows builds. Anything else would be a lie,
since the next patch is currently implemented only on that platform.
We'll need other platforms too. That means help would be helpful, or maybe
people will find me camped on their machines soon...
As for other platforms, doesn't Linux already have this with the -remote argument?
Attachment #158397 - Flags: review?(bryner)
Attachment #158396 - Flags: review?(bryner)
Attached patch finish implementation of pref UI (obsolete) — Splinter Review
Slight tweak to pref UI. It's still Windows-only (see comment 79). -remote
needs to be looked at (comment 81) and it isn't hooked up to this code yet.
Attachment #158396 - Attachment is obsolete: true
Attachment #158396 - Flags: review?(bryner)
Attachment #158455 - Flags: review?(bryner)
Attachment #158397 - Attachment description: windows-only native hookup of base patch above → windows-only native hookup of base patch below
Updated base patch. Comment 78 still applies.
Attachment #158395 - Attachment is obsolete: true
Attachment #158459 - Flags: review?(jst)
Blocks: 257011
No longer depends on: 257011
Blocks: 258076
What exactly is supposed to happen with the prefs UI?

In comment 57 I suggested doing a little reorg so that all the tabbed stuff was
together and so that multimedia would be eliminated and the one pref there added
to browsing.  As I first understood comment 62, I thought this would happen, but
as I reread it it seems the exact decision has been put off to a later date. 
What's the decision here?  In attachment 158455 [details] [diff] [review] from my quick scan the reorg
isn't happening, which means that tabbed prefs are strewn through the browsing
and tabbed browsing sections.

I need to know for bug 258076, which would document this (assuming it's allowed
as late-l10n, which in my completely biased opinion it should be because
otherwise the Help docs will be blatantly wrong).  I posted a halfway patch, but
primarily because the state of a prefs reorg isn't clear it was turned down (not
unexpectedly, but not for the reasons I wanted).
Same UI as before, but include a rearrangement of tabbing prefs as discussed in
comment 57. We seem to have implicit approval for this from Ben in comment 62.
Attachment #158455 - Attachment is obsolete: true
Attachment #158455 - Flags: review?(bryner)
Attachment #158695 - Attachment is obsolete: true
Attachment #158696 - Flags: review?(bryner)
Is this going to miss the boat for 1.0? If it is, I'd like to know so that I 
can plan to rip out all of the code that myself and another person spent a 
while perfecting ;-)
Comment on attachment 158459 [details] [diff] [review]
base code to control where external links are opened

- In browser/base/content/browser.js:

+const nsCI		  = Components.interfaces;
...
+nsBrowserAccess.prototype =
+{
+  QueryInterface : function(aIID)
+  {
+    if (aIID.equals(Components.interfaces.nsIBrowserWindow) ||
+	 aIID.equals(Components.interfaces.nsISupports))

Since you define nsCI above, you should use it here too...

r=jst
Attachment #158459 - Flags: review?(jst) → review+
Attachment #158459 - Flags: superreview?(peterv)
Just couple comments after building and testing Firefox with the latest patches
from this bug.

1) It seems to work pretty well, haven't had any problems so far. It doesn't
force javascript links into new tabs though, but I don't think this was meant to
cover them in the first place? (For example, clicking a link in an gmail email
opens a new window even with 'Force links that open in new windows open in' set
to new tabs)

2) 'Visit Home Page' links in Extensions/Themes managers always open in new
windows, in my opinion these should honor the set Tabbed Browsing options.

3) An option to force Firefox to remain on the background would be nice, that
way you could just click all links (in an email, for example) and then switch to
Firefox instead of clicking a link, switching the focus back to the email client
after Firefox steals it, click another link etc.
Agreed with comment 89.
Thoughts on window.open: this is something where more care should be taken. I
may sound obvious or redundant here, but as I haven't seen this idea being
commented/implemented ever (neither on this bug nor on extensions that reproduce
this behavior), this is my suggestion: only open new tabs instead of windows for
links which don't specify any options (and, maybe, for links that specify
options that reproduce a default-looking browser window). If a link specifies,
for example, width/height or toolbar=no, it most likely intends to open a small
popup window, and creating a new tab window (where most people use maximized
browsers) will look quite ugly.
If the user really desires to open every single window.open call in a new tab,
there could be a hidden preference for that -- or, if you prefer, another
option, though IMHO that would be much more like clutter for the average user.
(In reply to comment #89)
> 3) An option to force Firefox to remain on the background would be nice, that
> way you could just click all links (in an email, for example) and then switch to
> Firefox instead of clicking a link, switching the focus back to the email client
> after Firefox steals it, click another link etc.

IMHO, that might be nice but it's kinda a different bug, no?

(In reply to comment #90)
I totally agree... it doesn't make sense to open *everything* in a new tab, and
often that's the only reason for using javascript instead of just a link -
although sometimes it's for popups.

How do these patches affect Linux/Mac OS X/etc. users?  How crucial is it to
implement this in those?  I mean, if it means that all Linux users get options
in the UI that do nothing, imho it should wait until after 1.0 or something...

-[Unknown]
From comment 89:
> 3) An option to force Firefox to remain on the background would be nice, that
> way you could just click all links (in an email, for example) and then switch to
> Firefox instead of clicking a link, switching the focus back to the email client
> after Firefox steals it, click another link etc.

I agree that this should be a separate bug, though probably not that necessary.
 I was able to click on the link in Thunderbird, and still read e-mail until I
switched to Firefox to read.  How I did this was after clicking on the link, I
switched to another unread message, and Firefox stayed in the background. 
Sometimes, it's better to click and read, so it should be a user pref, key
combo, or an extension.  Definately another bug though.
comment 89: The patch as it stands has two problems that I know of: it works
only when the frontmost window's primary tab is active; it only works well with
http://-type links, e.g. not file:// or about:. Just a forewarning; you'll find
those bugs quickly enough. I have them corrected in my build but the glacial
speed of reviews discourages me from restarting the process with new patches.
Note to reviewers: the patches given require some small tweaks. Don't let that
stop you.

As you say it doesn't work for javascript: links containing script that opens a
new window. I'm not sure whether that's part of this bug's mission. Maybe. I'm
running with an additional patch that does just that, but I haven't posted it
yet because I'm still evaluating it and I expect troubles from it. For one thing
even that patch is unable to correct the longstanding error that
middleclick-in-new-tab will fail on such links.

An option to force FF to remain in the background while you fill it with tabs
would be slick. I'd use that. But it's outside the scope of this bug and it
could be problematic, depending on whether the choice of activating the program
after it opens the link is entirely up to the program on a given OS.

comment 90, 91, 92: I see your point but I'm not sure what heuristic to use to
determine whether a new window should submit to becoming a tab, since defining
an average coding behaviour for web authors is a task for madmen. Regardless
this would apply only to javascript:window.open-type links, which we've covered
above. Given our time constraints, this may be a post-1.0 tweak we're discussing.

comment 91: This patch is cross-platform for opening links from within the page.
The part about external links is implemented only on Windows. That part of the
UI is turned off on non-Windows platforms. (Actually in the current posted patch
the whole UI is turned off, but that's unnecessary.) I could take a donated
patch for that functionality on those platforms, but I'm prepared to do it
myself and I know pretty much what needs to be done and where. I'm just not
interested in getting started until the overall direction passes review. It's
only halfway there.
Dan (comment 93): my suggestion of heuristics is pretty simple: an option-less
call goes for a new tab. Example:
Open in new tab: window.open("x.html"); window.open("y.html", "somename");
Open in new window: window.open("z.html", "somename", "toolbar=no,status=no");

If you want another approach: open in a new window any call that features any of
these options: left, top, width, height.
I don't think popup windows (the ones that intend to be useful popups, not just
opening new windows) would not have width/height option parameters.

I just made a quick-hack check (replacing top.window.open with a custom
function) and Gmail seems to use window.open() with no parameters other than URL
for external links, so the first approach would work there. But to be more sure
maybe somebody should try using Venkman there.
*Developers, please ignore this message*

I am new to firefox development, and wish to use this new feature what you have
done. Where can I get the working copy of mentioned comment #89. Night build?

Regards
(In reply to comment #91)
> How do these patches affect Linux/Mac OS X/etc. users?  How crucial is it to
> implement this in those?  I mean, if it means that all Linux users get options
> in the UI that do nothing, imho it should wait until after 1.0 or something...

As crucial as it is to do it for the Windows users, IMHO.  Look, I know the
number of windows users of FF spectacularly dwarf the size of the Linux/Mac OS X
crowd, but it's damned unfair to leave us out of the equation.  This feature has
already been available for the Windows crowd in the Tab Browser Extensions
extension, but so buggy for non Windows users, it's almost unusable.  Could this
be also be a priority for the Mac crowd?
Attachment #158459 - Flags: superreview?(peterv)
Updated base patch for Aviary branch. I've made changes enough while waiting
that I thought a new patch was in order. This is like the previous patch r+ed
by jst with these changes:

Changed the names of the prefs. Call me Arbitrary.
Made C++/JS contact the chrome window rather than the content window (bug fix).

Use nsIURI rather than nsIURL (bug fix).
Fetch pref every time in nsDocShell, rather than caching. (Caching was
  confusing. Alternatively we could go with
nsIPrefBranchInternal->AddObserver.)
Replaced browser.block.target_new_window, now redundant.

Dangit I'm planning on keeping my r+ from jst on the previous patch but maybe
you guys should look again.
Attachment #158459 - Attachment is obsolete: true
Attachment #159442 - Flags: superreview?(peterv)
Attachment #159442 - Flags: review?(jst)
Attachment #158696 - Flags: review?(bryner)
Attachment #158397 - Flags: review?(bryner)
Attachment #157002 - Attachment is obsolete: true
Attached patch pref UISplinter Review
Attachment #158696 - Attachment is obsolete: true
Comment on attachment 159444 [details] [diff] [review]
pref UI

Like the previous (unreviewed) UI patch, but updated to match the latest base
patch above. Also includes a bug fix.
Attachment #159444 - Flags: review?(bryner)
comment 96: read comment 93.
Attachment #158397 - Attachment is obsolete: true
Attachment #159445 - Flags: review?(bryner)
Attachment #159443 - Flags: review?(jst)
For the Linux guys: Edit the firefox shell-script. Search for the line
#_open_type="tab". Remove the # and add it to the line above with "window".

I'd really like to know why this isn't the default in
mozilla/browser/app/mozilla.in.
(In reply to comment #96)
> (In reply to comment #91)
> > How do these patches affect Linux/Mac OS X/etc. users?  How crucial is it to
> > implement this in those?  I mean, if it means that all Linux users get options
> > in the UI that do nothing, imho it should wait until after 1.0 or something...
> 
> As crucial as it is to do it for the Windows users, IMHO.  Look, I know the
> number of windows users of FF spectacularly dwarf the size of the Linux/Mac OS X
> crowd, but it's damned unfair to leave us out of the equation.  This feature has
> already been available for the Windows crowd in the Tab Browser Extensions
> extension, but so buggy for non Windows users, it's almost unusable.  Could this
> be also be a priority for the Mac crowd?

As a FF user on both Mac and Windows, I have to agree with comment #96.  I
realize that platforms would not deliberately be excluded w/o a reason, but I
think a lot of people are unclear as to what the reason is.  TBE takes care of
this functionality with a beautiful amount of configurability, but on Mac TBE is
really slow and buggy.  Is there a way to implement this functionality via a
script/config change?

Also, since there is a need to keep the UI for this feature simple for the
"average Joe" user, it would be nice if any configuration options that are
deemed too confusing/complex be displayed in the UI be enabled in the config w/o
a UI.

Just my 2.
"Look, I know the number of windows users of FF spectacularly dwarf the size of
the Linux/Mac OS X crowd, but it's damned unfair to leave us out of the equation."

It seems to me with the -remote options, Linux users already have the majority
of this, and have had for years. I'm just glad Windows users finally get the
same feature.
attachment 159442 [details] [diff] [review]

for dom/public/idl/base/nsIBrowserWindow.idl, please move the doxygen comment
directly before the interface definition, so that doxygen actually knows that
the comment belongs to the interface

nsDocShell.cpp
+            NS_ASSERTION(0, "Can't get nsIDOMWindowInternal from nsDocShell!");

while touching this, please make it NS_ERROR

attachment 159443 [details] [diff] [review]

+      ios->NewURI(url, 0, baseURI, getter_AddRefs(tabURI));

you could use NS_NewURI; but in any case, please do pass a charset. looks like
you can use nsIDocument::GetDocumentCharacterSet for this

+        if (domReturn && !nameString.EqualsIgnoreCase("_blank"))

.LowerCaseEqualsLiteral

Camino has implemented some of this functionality. Perhaps code to implement
this on Mac OS X can be gotten from the Camino source base.
(In reply to comment #89)
...
> 3) An option to force Firefox to remain on the background would be nice, that
> way you could just click all links (in an email, for example) and then switch to
> Firefox instead of clicking a link, switching the focus back to the email client
> after Firefox steals it, click another link etc.

Didn't it used to work this way? Somehow I remember that being the case. I would
also like to see this.
Comment on attachment 159442 [details] [diff] [review]
base code to control where URLs are opened

r=jst
Attachment #159442 - Flags: review?(jst) → review+
Comment on attachment 159443 [details] [diff] [review]
optional addition to divert window.open to a new tab

- In GlobalWindowImpl::OpenInternal():

       rv = SecurityCheckURL(url.get());
   }
[...]
+  if (divertOpen) {
+
+    // construct URI, in case we need it
+
+    nsCOMPtr<nsIURI> tabURI;
+
+    nsCOMPtr<nsIIOService> ios(do_GetService(NS_IOSERVICE_CONTRACTID));
+    if (ios) {
+      nsCOMPtr<nsIDOMDocument> domdoc;
+      nsCOMPtr<nsIURI> baseURI;
+      GetDocument(getter_AddRefs(domdoc));
+      nsCOMPtr<nsIDocument> doc(do_QueryInterface(domdoc));
+      if (doc)
+	 baseURI = doc->GetBaseURI();
+
+      ios->NewURI(url, 0, baseURI, getter_AddRefs(tabURI));

This uses the base URI of the document in the window on which open() is being
called, but SecurityCheckURL() (rightfully) uses the base URI of the document
in the window where the call comes from. Do the same here. Split out the code
in SecurityCheckURI() into a helper if you want to...

r=jst with that fixed.
Attachment #159443 - Flags: review?(jst) → review+
I was thinking that this will probably eliminate maybe 4 or 5 extensions for me.

One I am not too sure of though is the one for when a new window opens when you
go to download which is fixed here.
http://forums.mozillazine.org/viewtopic.php?t=61134

I'm not sure if this fits with the context of this bug or not, but wanted to
mention it before it was too late.
Attachment #159444 - Flags: review?(bryner) → review+
Comment on attachment 159445 [details] [diff] [review]
windows-only native hookup of external URL control

>--- toolkit/xre/nsNativeAppSupportWin.cpp	5 Aug 2004 03:49:23 -0000	1.6.6.7
>+++ toolkit/xre/nsNativeAppSupportWin.cpp	19 Sep 2004 22:53:31 -0000
>@@ -1572,13 +1583,48 @@ nsNativeAppSupportWin::OpenBrowserWindow
>             // Have to open a new one.
>             break;
>         }
>+
>+        nsCOMPtr<nsIBrowserWindow> bwin;
>+        { // scope a bunch of temporary cruft
>+          nsCOMPtr<nsIWebNavigation> navNav( do_GetInterface( navWin ) );
>+          nsCOMPtr<nsIDocShellTreeItem> navItem( do_QueryInterface( navNav ) );
>+          if ( navItem ) {
>+            nsCOMPtr<nsIDocShellTreeItem> rootItem;
>+            navItem->GetRootTreeItem( getter_AddRefs( rootItem ) );
>+            nsCOMPtr<nsIDOMWindow> rootWin( do_GetInterface( rootItem ) );
>+            if ( rootWin ) {
>+              nsCOMPtr<nsIDOMWindowUtils> utils( do_GetInterface( rootWin ) );
>+              if ( utils )
>+                utils->GetBrowserWindow( getter_AddRefs( bwin ) );
>+            }
>+          }
>+        }
>+        if ( bwin ) {
>+          nsCOMPtr<nsIIOService> ios(do_GetService(NS_IOSERVICE_CONTRACTID));

We should probably just return if this fails (NS_ERROR_OUT_OF_MEMORY, perhaps).
 Also, make this block consistent with the ( parentheses style ) used
elsewhere.

>+          if ( ios ) {
>+            nsCOMPtr<nsIURI> uri;
>+            nsDependentCString urlStr(args);
>+            ios->NewURI( urlStr, 0, 0, getter_AddRefs(uri) );

Same here, return early IMO.

>+            if ( uri ) {
>+              nsCOMPtr<nsIDOMWindow> container;
>+              rv = bwin->OpenURI( uri,
>+                                  nsIBrowserWindow::OPEN_DEFAULTWINDOW,
>+                                  nsIBrowserWindow::OPEN_EXTERNAL,
>+                                  getter_AddRefs(container) );
>+              if ( NS_SUCCEEDED(rv) )
>+                return NS_OK;

If this really can't be expected to fail we might want to just assert and then
unconditionally return here, removing the code below this.  Is there a known
reason it would fail, where the code below is useful?
Yeah you caught me. The nsIBrowserWindow clause isn't expected to fail, but
still I cowardlyishily left in both fallback clauses. I'm good with putting an
assertion in place of fallback #1.

Actually as far as I can tell fallback #2 shouldn't ever be necessary either but
there are so many ways to get to it I'm uncertain. So I figure I should leave
that one in. How's this? (Note all of fallback #1, navigating the content window
directly, has been removed):

        if ( bwin ) {
          nsCOMPtr<nsIURI> uri;
          nsDependentCString urlStr( args );
          NS_NewURI( getter_AddRefs( uri ), urlStr, 0, 0 );
          if ( uri ) {
            nsCOMPtr<nsIDOMWindow> container;
            rv = bwin->OpenURI( uri,
                                nsIBrowserWindow::OPEN_DEFAULTWINDOW,
                                nsIBrowserWindow::OPEN_EXTERNAL,
                                getter_AddRefs( container ) );
            if ( NS_SUCCEEDED( rv ) )
              return NS_OK;
          }
        }

        NS_ERROR("failed to hand off external URL to extant window\n");
    } while ( PR_FALSE );

    // open a new window if caller requested it or if anything above failed
Comment on attachment 159445 [details] [diff] [review]
windows-only native hookup of external URL control

That sounds ok to me.
Attachment #159445 - Flags: review?(bryner) → review+
Comment on attachment 159445 [details] [diff] [review]
windows-only native hookup of external URL control

That sounds ok to me.
Attachment #159442 - Flags: approval-aviary?
Attachment #159444 - Flags: superreview?(bugs)
Attachment #159444 - Flags: approval-aviary?
Attachment #159445 - Flags: superreview?(blizzard)
Attachment #159445 - Flags: approval-aviary?
Attachment #159443 - Flags: superreview?(peterv)
Attachment #159443 - Flags: approval-aviary?
Comment on attachment 159444 [details] [diff] [review]
pref UI

Please do not check in the change to pref-advanced.dtd on the aviary branch.
(In reply to comment #115)
> (From update of attachment 159444 [details] [diff] [review])
> Please do not check in the change to pref-advanced.dtd on the aviary branch.

So, where do you want it to be shown?
*** Bug 245747 has been marked as a duplicate of this bug. ***
Comment on attachment 159445 [details] [diff] [review]
windows-only native hookup of external URL control

let's get some reviews before we consider for approval.
Attachment #159445 - Flags: approval-aviary?
Attachment #159444 - Flags: approval-aviary?
Attachment #159443 - Flags: approval-aviary?
Attachment #159442 - Flags: approval-aviary?
Flags: blocking0.9-
Blocks: 161466
Blocks: 227241
Comment on attachment 159442 [details] [diff] [review]
base code to control where URLs are opened

What biesi said, plus

> Index: docshell/base/nsDocShell.cpp
> ===================================================================

> @@ -1089,22 +1090,60 @@ nsresult nsDocShell::FindTarget(const PR

> +    if (mustMakeNewWindow) {
> +        rv = NS_ERROR_FAILURE;

Is this really necessary? Seems like we'll always set rv below.

> +        if (linkPref == nsIBrowserWindow::OPEN_NEWTAB) {
> +
> +          // try to get our tab-opening interface

I think this file uses 4-spaces indentation.
Attachment #159442 - Flags: superreview?(peterv) → superreview+
Yes we have no bananas. 

Sorry I've been busy this week travelling back to California. Sunday, I promise!
...updating my tree so I can apply these...
ok, where is nsIBrowserWindow? new file? no patch? my build is broken!
OK now this doesn't build for other reasons, I'm going to clobber my whole tree....
*** Bug 261872 has been marked as a duplicate of this bug. ***
Comment on attachment 159444 [details] [diff] [review]
pref UI

sr+a=ben@mozilla.org
Attachment #159444 - Flags: superreview?(bugs)
Attachment #159444 - Flags: superreview+
Attachment #159444 - Flags: approval-aviary+
Comment on attachment 159445 [details] [diff] [review]
windows-only native hookup of external URL control

sr+a=ben@mozilla.org
Attachment #159445 - Flags: superreview?(blizzard) → approval-aviary+
Comment on attachment 159442 [details] [diff] [review]
base code to control where URLs are opened

a=ben@mozilla.org
Attachment #159442 - Flags: approval-aviary+
jst and I are united in our vigilant and tenacious stance against invading
mozilla/browser namespace from mozilla/dom IDL, so
s/nsIBrowserWindow/nsIDOMBrowserWindow/g -- including the filename, natch.

/be
shouldn't that be nsIDOMNSBrowserWindow to avoid invading DOM namespace?
This bug's patch was not held up for all those days danm bitterly keeps count of
over a naming issue, so I won't hold it up now -- I said yesterday, "r+sr+a=me,
have a drink on me" to danm in person.

But according to our own poor-man's namespacing conventions, there ought to be
an nsIDOM on the front of the name.  We can fix this later if ever we care to,
or else ben or whoever promulgates the new base browser window interface can
obfuscate the name that emerges under browser in deference to this patch -- or
we can try to get all browser app owners to agree on common extensions (with
uuid changes) to dom/public/idl/base/nsIBrowserWindow.idl.

I dont' care, but little naming and modularity messes count, they add up and
make the tree hard to change, and harder than necessary for newcomers to learn.

Timeless points out an old Netscape-centric vidur convention for trying to avoid
invading the w3c interface namespace that follows the nsIDOM prefix, but it was
never guaranteed, Netscape is effectively dead, and the w3c DOM working group
has disbanded.

Check it in, already!  If you need 1.7 branch driver approval, dveditz can do that.

/be
Please don't change the nsIBrowserWindow name now, the app-startup patch would
be massively conflicted. We can do it later, if that's necessary.
Comment on attachment 159443 [details] [diff] [review]
optional addition to divert window.open to a new tab

>Index: dom/src/base/nsGlobalWindow.cpp
>===================================================================

>+    nsCOMPtr<nsIIOService> ios(do_GetService(NS_IOSERVICE_CONTRACTID));
>+    if (ios) {
>+      nsCOMPtr<nsIDOMDocument> domdoc;
>+      nsCOMPtr<nsIURI> baseURI;
>+      GetDocument(getter_AddRefs(domdoc));
>+      nsCOMPtr<nsIDocument> doc(do_QueryInterface(domdoc));
>+      if (doc)
>+        baseURI = doc->GetBaseURI();
>+
>+      ios->NewURI(url, 0, baseURI, getter_AddRefs(tabURI));
>+    }

I also would prefer NS_NewURI here.

>+  // lacking specific instructions, or just as an error fallback,
>+  // open a new window.
>+
>+  if (!domReturn) {
>     nsCOMPtr<nsIWindowWatcher> wwatch =
>       do_GetService(NS_WINDOWWATCHER_CONTRACTID, &rv);
> 
>-    if (wwatch) {
>+    if (!domReturn && wwatch) {

You already checked domReturn.

With what biesi and jst said, sr=peterv.
Attachment #159443 - Flags: superreview?(peterv) → superreview+
Amazing!

You guys have just removed the basic core of functionality provided by the
various tabbed browsing extensions. Thanks :) (no  seriously, external link
handling was a major pain to do with just JavaScript)

What exactly does attachment 159443 [details] [diff] [review] do? I see it has r+ and sr+, so it's going
to be checked in, but does it really do what it says - divert window.open calls,
namely the ones made by JavaScript, into tabs?
Comment on attachment 160667 [details] [diff] [review]
mac-only native hookup of external URL control (Aviary branch)

Requesting review. Note I also want to remove the now unused, Mac-only,
redundant pref browser.always_reuse_window from all.js (I just forgot to
include it in the diff). If you want to try this patch you must also use the
#ifdef XP_WIN version of
browser/components/prefwindow/content/pref-advanced.xul at line 43. I'll check
in that change once the Mac and Linux backends are all checked in.
Attachment #160667 - Flags: review?(pinkerton)
Attachment #160667 - Attachment description: mac-only native hookup of external URL control → mac-only native hookup of external URL control (Aviary branch)
Works great and thank you to everyone that woked on this my only gripe is...When
using the search bar, how can i get it to display results in a new tab?
(In reply to comment #136)
> Works great and thank you to everyone that woked on this my only gripe is...When
> using the search bar, how can i get it to display results in a new tab?

You can't. I've now read the patches and I don't see anything influencing how
the searchbar works. Attachment 159442 [details] [diff], the core of the new code, doesn't appear
to fool around with #searchbar in any way. TBP will continue to offer that bit
of functionality though.
> When using the search bar, how can i get it to display results in a new tab?
Press Alt+Return. Works in the location bar as well.
I know this comment is probably too late (for 1.0) but could:

Select new tabs opened from bookmark or history
Select new tabs opened from links

be changed in

Focus on new tab opened from Bookmark or History
Focus on new tab opened from links

I didn't understand the "select" and I wasn't the only one.


Comment on attachment 160667 [details] [diff] [review]
mac-only native hookup of external URL control (Aviary branch)

looks good to me, r=pink
Attachment #160667 - Flags: review?(pinkerton) → review+
Attachment #160667 - Flags: superreview?(neil.parkwaycc.co.uk)
Maybe a regression...can't remember what happend before.

When either left-clicking or middle-clicking the Extension manger on 'Get More
Extensions' a new window opens, clicking on 'Visit Home Page' on the context
menu in the extension manager and Theme manager same thing for 'Get More Themes'. 

and yes all of my settings are correct
Can't wait to find out what I did wrong in this patch! This leaves the option
to specify new-tab or new-window intact, but makes a remote command lacking any
such spec do as dictated by the prefs.

The "if you want to try this patch" part of comment 135 also applies to this
patch.

PS I replaced the old notification broadcast technique for opening new tabs
because the new technique is more flexible, and I needed that flexibility in
DocShell. I have a table of all the methods that I could find for opening new
tabs used throughout the program, and which are good for what. It's impressive.
I'm adding yet another, and I'm trying to do a little consolidation.
Attachment #160692 - Flags: superreview?(bryner)
Attachment #160692 - Flags: review?(blizzard)
(In reply to comment #139)

See bug 246274 comment 13 and bug 246274 comment 14.  (Please also note that
your concern is irrelevant to this bug and should have been voiced elsewhere.)
*** Bug 262409 has been marked as a duplicate of this bug. ***
Finally! Someone points me to the bug to fix one of my longest-standing gripes
about Firefox and browsers in general -- the incredibly annoying window clutter
that results after only a few minutes of browsing because every web developer
out there seems to think they need to open a new window for seemingly every link
on all their sites. Why this is is I don't know, since it's not that difficult
to hold down a key while you click the mouse to open a window/tab if you want to
open a new window.

Anyhow, I'm not a programmer, but I felt some comments would hopefully be
well-received by those who are working on this issue.

On some sites this seems to work for me
(http://forums.vwvortex.com/zerosearch?cmd=recenttopics forces the links to
topics you've posted in recently to load in the same window, for instance) while
not in others (like
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=Retrieve&db=PubMed&dopt=Citation&list_uids=11208057
-- clicking on the image that leads to the article spawns a new window). That's
inconsistent. If I've selected options to force links to open in new windows, I
want them to always do so.

I still find that the UI for controlling outside-app links, listed in comment
56, is missing. Presumably it's still being worked on, but I sorely miss it;
xJournal (a Livejournal client) spawns a new window rather than a new tab when
you tell it to check the friends page, thus contributing to window clutter.

My build info is:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20041001
Firefox/0.10
danm, thanks a lot for fixing this.

One thing though, if "Select new tabs opened from links" is unchecked, your code
does not select the tabs it creates, which is quite confusing and inconvienient.

This is reported as bug 262537. As I said there, the "Select new tabs opened
from links" option should apply to middle-clicked links, not left-clicked ones.
No longer blocks: 227241
*** Bug 227241 has been marked as a duplicate of this bug. ***
*** Bug 227241 has been marked as a duplicate of this bug. ***
I have to say I agree with comment 146, although such a change would require the
already difficult to phrase options to be relabeled to clarify the left vs
middle click behavior.
(In reply to comment #141)
> When either left-clicking or middle-clicking the Extension manger on 'Get More
> Extensions' a new window opens, clicking on 'Visit Home Page' on the context
> menu in the extension manager and Theme manager same thing for 'Get More Themes'. 
> 
> and yes all of my settings are correct
Please see Bug 262575.
This type of URL is still popping up a new window with "new tab" enabled.

<a href="#"
onClick="window.open('http://sports.espn.go.com/nfl/gamecast/index','Popup','width=780,height=540,scrollbars=no,noresize');
return false">GameCast</a>
mmortal03:
see comment 94 and comment 98. The pref to change behavior is
browser.link.open_newwindow.restrict
0 means no restrictions. 1 means only if no options
(In reply to comment #152)
> mmortal03:
> see comment 94 and comment 98. The pref to change behavior is
> browser.link.open_newwindow.restrict
> 0 means no restrictions. 1 means only if no options
> 

Thanks.  Problem is, that link still opens in a new window, even with
browser.link.open_newwindow.restrict set to 0.  I double and triple checked for
spelling errors.  To try out that link directly, go to www.espn.com , and click
on any of the Gamecast links in the left sidebar.
Dan, I filed bug 262977 and bug 262978 for issues with focusing and links from
external applications. Both are quite confusing for users.
(They are filed as UNCO because I can't get a recent build to test with. Please
somebody on current nightly confirm them)
mmortal03:

I was having your problem. I did a dig through the source and the pref has been
changed to browser.link.open_newwindow.restriction. It can have the following
values:

0: no restrictions - divert everything
1: don't divert window.open at all
2: don't divert window.open with features
Great progress on this bug.  I see that checkins have been made in the Aviary,
but I was wondering about the possibility of this functionality in Seamonkey.  

Could anyone let me know if Seamonkey implementation is planned?  Thanks.
(In reply to comment #151)
> This type of URL is still popping up a new window with "new tab" enabled.
> 
> <a href="#"
>
onClick="window.open('http://sports.espn.go.com/nfl/gamecast/index','Popup','width=780,height=540,scrollbars=no,noresize');
> return false">GameCast</a>

The ESPN URL is now 404 but when I tried it earlier it didn't open a new window
for me.  However I am still having problems with the PubMed link I listed
earlier -- checked the source and it does look like it is using window.open to
open new windows. I have both prefs set to 0 as type 'integer' in about:config.
Am I doing something wrong?
Has this been checked into the 0.10 branch ("latest-0.9")?  I see a preference
for opening links in new window or new tab (force links that open in new
windows...) but that only applies to links inside Firefox -- the control for
links from external applications doesn't seem to be landed.
There was a time when bugzilla pages were attuned more toward getting the bug
fixed than a question and answer forum. I miss those days.

Comment 154: thanks.
Comment 155: sigh.
Comment 156: sure.
Comment 157: this bug is still under construction.
             window.open is unaffected in builds before Oct 4.
Comment 158: see comment 93, comment 134, comment 142.
Comment 159: release the bugspam!
Dan, are technical comments on the patches ok?

In particular:

1)  The nsGlobalWindow.cpp changes only check for the name "_blank"; they should
    also check for "_new" (see the actual targeting code in docshell, eg).
2)  These same changes break window.open() into a previously opened window or
    frame, as far as I can tell, for the case when 
    |containerPref ==   nsIBrowserWindow::OPEN_NEWTAB| (it'll now load in a new
    tab, even if a frame/tab/window with that name already exists).

The second issue is likely to bite on a lot of sites if users set that pref...

On a non-code tangent, I hope this'll be landing on trunk someday too? ;)
The links in my feedlist on bloglines.com don't work anymore if I set Firefox to
open links in new tabs. Instead of opening the news items in the other frame,
Firefox opens a blank tab. 

This is the code which is used:

function doLoadf(index,subid,siteid) 
{
  parent.basefrm.location.href = '/myblogs_display?sub='+subid+'&site='+siteid;
  subNoUnread(index,subid,siteid);
}

...
 aux = insDoc( cFolder, 
          jitem = gLnk("S", "  The Burning Edge  ", 
               "javascript:doLoadf(6,1595305,9394)", "title=\"  The Burning Edge
 \"", "", "9394" ))
...

If browser.link.open_newwindow.restriction is set to 1 the problem doesn't exist. 
Whiteboard: l10n changes landed on aviary branch → [have patch] need reviews for linux and mac
Comment on attachment 160692 [details] [diff] [review]
linux-only native hookup of external URL control (Aviary branch)

The logic looks good to me.
Attachment #160692 - Flags: review?(blizzard) → review+
Boris: Thanks for catching that. Here's a patch for you to review :)

By the way can I just say that window targeting by name is so very, very messed
up all throughout Mozilla. The appearance of it mostly working is dependent on
the way all the different broken subroutines support each other into a mostly
functional whole. See bug 103638.

Anyway, this patch will fix comment 160 and probably comment 161, which sounds
like the same thing, as well. Gert-Paul, please try your problem with this
patch (wait for it to land if you must) and if your problem still persists,
start a new bug, attach a usable testcase, and assign it to me.
Attachment #161419 - Flags: superreview?(jst)
Attachment #161419 - Flags: review?(bzbarsky)
Comment on attachment 161419 [details] [diff] [review]
don't divert window.open to a new tab if the named window exists

> window targeting by name is so very, very messed up

Agreed.  We need some itility functions (possibly on windowwatcher?  Or
something?) to deal with it, at the least -- the copy/paste of code between
here, docshell, and windowwatcher is incredibly uncool.

In fact, it'd be nice to see such utility functions land on trunk along with
this patch, if you're up to it...  If not, please file a followup bug on that
specific issue and cc me.

>Index: dom/src/base/nsGlobalWindow.cpp
>+  nsAutoString nameString(aName);
...
>+  if (nameString.EqualsIgnoreCase("_top") ||
>+      nameString.EqualsIgnoreCase("_self") ||
>+      nameString.EqualsIgnoreCase("_content") ||
>+      nameString.EqualsIgnoreCase("_parent") ||
>+      nameString.Equals(NS_LITERAL_STRING("_main")))

This is ok for branch, but for trunk this should use LowerCaseEqualsLiteral and
EqualsLiteral respectively, both just called on aName.

>-  if (!aExtraArgument) { // divert only if no extra argument
>+  if (divertOpen) { // no such named window

Any reason to push the !aExtraArgument check down below the QI here?  It looks
like it just makes us do an unnecessary QI sometimes, since the QI result is
effectively ignored if aExtraArgument.

r=bzbarsky with that.

Eagerly awaiting trunk patches for this stuff, too.  ;)
Attachment #161419 - Flags: review?(bzbarsky) → review+
Attached image Desktop clutter :)
For your enjoyment: the current state of things :)
 
Am glad this subject is being taken care of.
I just noticed this isn't quite working 100% yet, and I thought it was.

Not sure if this one applies here or not:

Go to http://boston.redsox.mlb.com/NASApp/mlb/index.jsp?c_id=bos

and click on game day button (around 9 o'clock) and a new window pops open,
though all my other ones open in new tabs.
I think we need to create a sticky for the option
browser.link.open_newwindow.restriction.  :)

Sasquatch Bigfoot, please try this option, and set it to 0. I had the same
problem as you did, and this is the solution, as discussed earlier in this thread.
I think we need to create a sticky for the option
browser.link.open_newwindow.restriction.  :)

Sasquatch Bigfoot, please try this option, and set it to 0. I had the same
problem as you did, and this is the solution, as discussed earlier in this thread.

Might it be better to have 0 as the default for this option?  It seems that when
people choose to have all windows open in a a new tab, they MEAN all windows. 
This is confusing when some windows don't follow this.
Comment on attachment 161419 [details] [diff] [review]
don't divert window.open to a new tab if the named window exists

sr=jst
Attachment #161419 - Flags: superreview?(jst) → superreview+
(In reply to comment #168)
> ... It seems that when
> people choose to have all windows open in a a new tab, they MEAN all windows. 
> This is confusing when some windows don't follow this.

This is what it does mean, and it IS confusing.
*** Bug 263643 has been marked as a duplicate of this bug. ***
Using this enhancement has amplified Bug 131456 .  Now that we have a Single
Window Mode, it is necessary that closing tabs release memory in the same way
that closing windows does.  I am finding firefox.exe using up a lot of memory
after a day of keeping the same window open and just opening new tabs (which
shouldn't be a problem, but is).
Comment on attachment 160667 [details] [diff] [review]
mac-only native hookup of external URL control (Aviary branch)

rs=me for the branches but it would be nice to have the nsIBrowserDOMWindow
object stored as an attribute of the nsIChromeWindow.
Attachment #160667 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #160667 - Flags: superreview+
Attachment #160692 - Flags: superreview?(bryner) → superreview+
Whiteboard: [have patch] need reviews for linux and mac
Target Milestone: Firefox1.0beta → Firefox1.0
I think bug #263844 is a regression from this?
A popup opened in a tab using java script is not allowed to window.close(); itself.
No. That's a very old bug.
Dan, how so?  Popups opened via window.open() can close themselves fine here (on
trunk, at least).  So if they can't do it after being forced into a tab, the
problem is in the code forcing them into a tab, no?  Or at least in the way
window.close() is handled for tabs (which would indeed be a very old bug, but
we're exposing it, all of a sudden.  Prior to this checkin, the only way to
expose it was to manually open tabs in a popup window).
Yes, it's just that it's more exposed now. window.close() has never, ever worked
on windows opened into a tab. This discussion should be moved to that other bug.
Dan, until this checkin there _weren't_ any such windows, is the point.
at the end of this page (comments part):
http://www.ynet.co.il/articles/0,7340,L-2989051,00.html

the window.open heght & width features unexpectedly affect the current window
(not as other window features). However the following testcase _doesn't_ have
this behavior:

----------------
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
 <head>
   <title>testcase</title>
   <meta http-equiv="Content-Type" content="text/html; urf-8">
 </head>
 <body>
    <a href="javascript:void(0);"
      onclick="window.open('about:blank', 'test',
'toolbar=no,location=no,directories=

no,status=yes,menubar=no,scrollbars=auto,movable=yes,resizable=no,width=430,height=417')

;">
      Click me
    </a>
 </body>
</html>
----------------
Boris:
>>window.close() has never, ever worked on windows opened into a tab.
>Dan, until this checkin there _weren't_ any such windows, is the point.

I don't see the distinction between tabbed windows introduced by this
enhancement, and middle-click tabbed windows.

Asaf: 
If that was a bug report, please write it up so that I can understand what to do
and what to expect, and put it in a new bug.
danm, the difference is that script never opened middle-click tabs, so it can't
reasonably expect to close them. But since script is now opening tabs through
redirected window.open, it has every expectation that it will be able to close
those windows.
Actually, bz, those types of tabs/windows _have_ existed before this patch.
Being an exclusive tab-browser person, I've seen it hundreds of times, but as
you said yourself in #176.
>danm, the difference is that script never opened middle-click tabs, so it can't
>reasonably expect to close them. But since script is now opening tabs through
>redirected window.open, it has every expectation that it will be able to close
>those windows.

Nor can script open left-click tabs in current nightlies. The decision of
whether to tab a new window is, as always, up to the program and the user's prefs.

Firefox 0.8: User left-clicks <a target="_blank">: new window can be closed from
script. User middle-clicks same link: new window (tab) cannot be closed from
script. Now can we please take this to the relevant bug? Feel free to + it too
if you believe this old bug's recent increased visibility makes it more important.
After reading the comments, I can't tell if this bug will be fixed in Mozilla or
only in Firefox.  There are indeed related Mozilla bugs (e.g. bug 231984).  

Three of the four open bugs this one blocks are "Browser" and not "Firefox".  If
this enhancement is not going to be implemented in the Mozilla browser, how does
it block other bugs for the Mozilla browser?  
I've been using this feature on linux fc2 for several days, and it works nicely
so far (eg, links from thunderbird open in new/same tab in firefox, ditto for
links in gaim).
(In reply to comment #107)
> (In reply to comment #89)
> ...
> > 3) An option to force Firefox to remain on the background would be nice, that
> > way you could just click all links (in an email, for example) and then switch to
> > Firefox instead of clicking a link, switching the focus back to the email client
> > after Firefox steals it, click another link etc.
> 
> Didn't it used to work this way? Somehow I remember that being the case. I would
> also like to see this.

It was working here this way with 2004100505 (all external links were opened in
the background *g* ). Unfortunatelly in 2004101414 the behaviour changed. Did
anything change between these two builds? 
BTW: Is there a new bug regarding 3)? Or is there now an option to open links
from external apps in the background?
Clicking on a link in Thunderbird does not bring it up at all (it does nothing)
in Firefox from today (10/18/2004). 

The same version Thunderbird with Bangbang023's and the "official" 10/14 build
opens the link fine, so it is NOT a Thunderbird issue. This is with the Bangbang
or 10/14 "official" build already open. With today's "official build" already
open, it does nothing. It also won't open anything if no browser open, where it
used to open the default browser before.
*** Bug 255504 has been marked as a duplicate of this bug. ***
*** Bug 266078 has been marked as a duplicate of this bug. ***
Bug 246274 is now showing as closed, but the terminology in the preferences
panel remains very confusing and the preference panel UI does seem to be under
discussion in this bug (comment 56), so while not wishing to draw the ire seen
in comment 143, I *think* that this is relevant to this bug track. If I'm wrong,
and I should be reopening 246274, I'm sure someone will let me know :)

There was a proposal for what seems like a sensible compromise (bug 246274
comment 16) of "switch to". That would make the prefs UI look like:

Tabbed Browsing
(...)
  [ ] Switch to new tabs opened from links
  [ ] Switch to new tabs opened from bookmarks or history
(...)

But to me, even that is confusing. I propose that the confusion lies in the fact
that the preference is an on/off toggle, but the statement contains two verbs
(switch and open) which makes it harder to parse. By reversing the preference so
that it describes a single action, it becomes much easier to understand: 

Tabbed Browsing
(...)
  [ ] New tabs from links open in background
  [ ] New tabs from bookmarks or history open in background
(...)
I, uh, forgot to make it explicit, but I guess the proposal for the terminology
change also means reversing the effect of the checkbox. I suppose the strings
could be "... open in foreground", but that seemed a little less intuitive to
me. YMMV.
The new version of the prefs is much clearer. 
#190 makes a lot more sense to me. Is that in Aviary yet? 
My monthly drive-by mass bug diligence:

Comment 184: What looks like an organizational observation is probably a request
to adapt the patch to the trunk and the Suite. I suppose this is a new
statement; after all this bug was opened specifically against Phoenix and
previous comments look forward only to a trunk adaptation.
  Sure, as far as I know the Suite wants this capability as well. It's not
ready. We don't have all the bugs worked out yet and frankly I'm a little tired
of Mozilla hacking right now.

Comment 186: Bug 263553.

Comment 187: I assume this problem has since magically evaporated.

Comment 190: Mike that argument has been going for months and it seems this bug
was where it took place. Still I consider it an ancillary issue and contentious
enough that it would be better served in a dedicated bug. For full flavour you
should bring comments 6, 54, 57, and 139, as well as similar comments from bugs
75138 and 121969 with you. By the way I prefer the current wording to the
proposal's. Discussion in a development forum or the new bug, please.

Comment 193: Eh?
There's an interesting issue, now on Linux.

It works pretty well when launching firefox with an argument set to a full url,
including protocol: stuff, but not when it is not included.

i.e. launching firefox www.google.com doesn't follow these settings while
firefox http://www.google.com does.
What is the official position on a new option to distinguish between regular
links and window.open calls when opening windows in a new tab?  A simple link in
a page is very different than a window.open call with specific size and layout
properties meant to be viewed in a specific format.

Should a new bug be opened?
Blocks: 103843
For the record, this fix introduced bug 267249, once this lands on the trunk,
we'll need to land that fix on the trunk as well...
Blocks: 267249
Still blocking Aviary? Need to change Target Milestone: to 1.1 and add a
blocking 1.1 field.
(In reply to comment #168)
> I think we need to create a sticky for the option
> browser.link.open_newwindow.restriction.  :)
> 
> Sasquatch Bigfoot, please try this option, and set it to 0. I had the same
> problem as you did, and this is the solution, as discussed earlier in this thread.
> 
> Might it be better to have 0 as the default for this option?  It seems that when
> people choose to have all windows open in a a new tab, they MEAN all windows. 
> This is confusing when some windows don't follow this.


I don't know if this was missed or not, but I wanted to reiterate that I second
the option to make 0 the default.
Blocks: 263956
I highly recommend that all who are interested in this look at how the Netscape
people have handled this in thier Firefox-derived browser.
*** Bug 272560 has been marked as a duplicate of this bug. ***
*** Bug 272638 has been marked as a duplicate of this bug. ***
(In reply to comment #200)
> I highly recommend that all who are interested in this look at how the Netscape
> people have handled this in thier Firefox-derived browser.

Agreed. The Netscape Preview makes tab options simple and easy to understand.
Why take up so much room with radio buttons when a pulldown menu does the same
thing?
(In reply to comment #203)
>
> Agreed. The Netscape Preview makes tab options simple and easy to understand.
> Why take up so much room with radio buttons when a pulldown menu does the same
> thing?

Sounds similar to what I did for TBP. Any screenshots?
(In reply to comment #204)
> Sounds similar to what I did for TBP. Any screenshots?

The specific Tab Browsing pane:
http://gemal.dk/misc/nsb09.png

Other screenshots of the new Netscape Browser:
http://gemal.dk/blog/2004/11/30/netscape_browser_screenshots/
Comment on attachment 160667 [details] [diff] [review]
mac-only native hookup of external URL control (Aviary branch)

File->New Window on mac when no window is open, was broken for some time on the
aviary branch.

Considering the points this patch touced, and that the regression isn't repro'
on latest trunk builds, I wonder if this one caused it.

Please double-check before landing it on the trunk.
this checkin changed nsIDOMChromeWindow.idl but did not change its uuid. this
will break binary compat with C++ code using this interface. please update its uuid.
> this checkin changed nsIDOMChromeWindow.idl but did not change its uuid. this
> will break binary compat with C++ code using this interface. please update its
uuid.

where did these interface changes land?  please please don't forget to change
the UUID of interfaces when they change.  it's the only thing that gives
extension authors and embedders a fighting chance at using non-frozen interfaces.
Did nsIDOMChromeWindow.idl's UUID not change on the aviary branch?  Or did it
change there but not on the trunk?

/be
This seems to be the right bug to comment, bonsai shows me the checkin "single
window mode aviary branch merge. bug 172962, 263689, 263844, 263960
r=bryner,jst,peterv" to mozilla/ docshell/ base/ nsDocShell.cpp

The problem with that checkin is that it seems to have killed the preference
browser.block.target_new_window that is widely used by Seamonkey addicts,
although it is still referenced in a few locations in the source. At least that
pref does no longer have any effect on target="_blank" links...
(In reply to comment #210)
> The problem with that checkin is that it seems to have killed the preference
> browser.block.target_new_window that is widely used by Seamonkey addicts,
> although it is still referenced in a few locations in the source. At least that
> pref does no longer have any effect on target="_blank" links...

This is not a bug. The pref is meaningless now and is replaced with the prefs
under the browser.link pref branch.
If it's meaningless, references to it should be removed from the tree and
relevant documentation should be updated accordingly...
Ed et.al. (comment 200, 203-205): I think "Netscape's" UI is better, myself. Why
not file an enhancement bug requesting a review of Firefox's UI? Such a concern
will not be addressed in this bug, which will be closed "fixed" soon.

Brendan, Darin (comment 208-209): The situation with nsIDOMChromeWindow's UUID
is all taken care of. Thanks to Christian for pointing out the problem.

Boris, Bradley, Peter (comment 210-212): browser.block.target_new_window was
completely excised from the trunk by the migration of this patch. Errr except
for one definition, completely unused, in embedding/minimo/all.js. That too
could be removed. Firefox 1.0 collected instances of this complaint for several
months as people adjusted, and now we'll see a similar wave of surprise pass
over the trunk.
Sorry for the confusion. I looked up "browser.block." using lxr and the files
displayed there obviously haven't been updated in in the last 2 days. At least
that's what I see, the files on my disk and from bonsai blame are OK.

I hope that someone makes sure that this is an item for the 1.8a6 release notes
as many Seamonkey users seem to have browser.block.target_new_window=true in
user.js.
Dan, mind updating http://www.mozilla.org/unix/customizing.html to reflect reality?
(In reply to comment #212)
> If it's meaningless, references to it should be removed from the tree and
> relevant documentation should be updated accordingly...

I think the documentation is key here to keep track of things. 
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a6) Gecko/20041208 Firefox/1.0+

Links from other applications now correctly open a new tab instead than a new
window, but they got focus even when "select new tabs opened from links" is
unchecked.
Single Window Mode is implemented in the Firefox 1.0 branch and on the trunk. On
the trunk I think there are problems with embedded or native apps like Camino,
and I expect there to be issues with external links in the Suite. Surprisingly
I've noticed no such bugs being filed. When such bugs do spring up, we'll deal
with them there. I'm sticking a fork in this one.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Oh. And comment 217, see bug 262537. And the Suite needs a UI. I'll leave that
too to another bug.
(In reply to comment #219)
> Oh. And comment 217, see bug 262537. And the Suite needs a UI. I'll leave that
> too to another bug.

I think that "other" bug might be 161466 .
Keywords: aviary-landing
Can someone please explain to me where the patch to nsIDOMChromeWindow.idl to add 

attribute nsIBrowserDOMWindow browserDOMWindow;

came from?

See:

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsIDOMChromeWindow.idl&branch=&root=/cvsroot&subdir=mozilla/dom/public/idl/base&command=DIFF_FRAMESET&rev1=1.5&rev2=1.6

I don't see it in any of the patches in this bug.

*** Bug 274834 has been marked as a duplicate of this bug. ***
Blocks: 274859
No longer blocks: 274859
What and when was the final fix on this bug? I seem to have lost something in
the translation here. Was it based off a 10/13 attachment? Thanks. Or should
this be a  "WONTFIX"? Thanks again.
For an education in flexibility and clarity of language, check out Tools >
Options > Tab Browsing in the second version of Netscape's prototype browser
based on Firefox.
(In reply to comment #218)
> Single Window Mode is implemented in the Firefox 1.0 branch and on the trunk. On
> the trunk I think there are problems with embedded or native apps like Camino,
> and I expect there to be issues with external links in the Suite. Surprisingly
> I've noticed no such bugs being filed. When such bugs do spring up, we'll deal
> with them there. I'm sticking a fork in this one.

FYI, for Camino the bug is bug 274143, but it's not so much a bug as a general
reminder and RFE; the old "pseudo-SWM" prefs, or a subset thereof that were
implemented, were never accessible via the UI.
(In reply to comment #223)
> What and when was the final fix on this bug? I seem to have lost something in
> the translation here. Was it based off a 10/13 attachment? Thanks. Or should
> this be a  "WONTFIX"? Thanks again.

Anyone?
it was marked fixed with comment 218
Depends on: 255123
(In reply to comment #168)
> I think we need to create a sticky for the option
> browser.link.open_newwindow.restriction.  :)
> 
> Sasquatch Bigfoot, please try this option, and set it to 0. I had the same
> problem as you did, and this is the solution, as discussed earlier in this thread.
> 
> Might it be better to have 0 as the default for this option?  It seems that when
> people choose to have all windows open in a a new tab, they MEAN all windows. 
> This is confusing when some windows don't follow this.


Was there ever a bug made up for this option?




(In reply to comment #194)
...
> Comment 190: Mike that argument has been going for months and it seems this bug
> was where it took place. Still I consider it an ancillary issue and contentious
> enough that it would be better served in a dedicated bug. For full flavour you
> should bring comments 6, 54, 57, and 139, as well as similar comments from bugs
> 75138 and 121969 with you.... Discussion in a development forum or the new
bug, please.

Did we ever get a bug number for this?
(In reply to comment #195)
> There's an interesting issue, now on Linux.

Same issue on Windows (XP), with Firefox 1.0.3 (French language)

If (gui) option is set to open external urls in new/current tab
(not on new window) -- without using the tabbrowser extension:

1. Using "firefox http://www.google.com" works as expected (new/current tab)
   ok

2. Using "firefox goole.com" open a new windows (not new/current tab)
   Looks like I discover the same BUG.

Hope this helps

(In reply to comment #228)

> (In reply to comment #194)
> > 75138 and 121969 with you.... Discussion in a development forum or the new
> bug, please.
> 
> Did we ever get a bug number for this?

The new labels for these preferences ("Select new tabs opened from ...") seem to
work pretty well, so I left it alone and didn't bother opening one, no.
*** Bug 105547 has been marked as a duplicate of this bug. ***
*** Bug 121969 has been marked as a duplicate of this bug. ***
*** Bug 121969 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
Blocks: 121969
No longer blocks: majorbugs
Blocks: 128632
I vote for: open links in last unpopulated, (untitled) or blank tab.
This is 2 years old, and has been implimented and resolved.

Status:  RESOLVED FIXED  
Severity:  enhancement  
Target Milestone:  Firefox1.0

I don't mean to be rude or anything, but what you're asking for seems to be more like a new request rather then an old.

It's a good idea in theory, we could just stop opening 5 thousand blank tabs all the time, but face it we're too lazy for that.

It would only be good for pages pointing to about:none, as a large amount of web pages are too lazy for <titles> also.
ok
Flags: blocking-firefox3.1?
Flags: blocking-firefox3.1?
Flags: blocking-firefox3.6?
Attached image screenshots (obsolete) —
Comment on attachment 377306 [details]
screenshots

(In reply to comment #237)
> Created an attachment (id=377306) [details]
> screenshots

Don't spam bugzilla with junk pictures that have absolutely nothing to do with anything.
Attachment #377306 - Attachment is obsolete: true
Flags: blocking-firefox3.6?
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0+
You need to log in before you can comment on or make changes to this bug.