Closed Bug 116653 Opened 23 years ago Closed 22 years ago

Implement -remote openURL(URL, new-tab)


(Core Graveyard :: X-remote, enhancement)

Not set


(Not tracked)



(Reporter: pajor, Assigned: shaver)


(Depends on 1 open bug)



(2 files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221
BuildID:    2001122108

Currently support is only for mozilla -remote openURL(URL, new-window).  With
the addition of tabbed browser support many people will want to be able to open
in a new tab from the command line or in apps such as gnome-moz-remote.

Reproducible: Always
Steps to Reproduce:
1. run mozilla -remote 'openURL(URL, new-tab)'

Actual Results:  Error since new-tab isn't an url

Expected Results:  Open the url in a new tab in an existing mozilla app
Looks similar to bug 104204 but I don't know the exact meaning of -remote.
Marking new as I can't find this elsewhere.
Removing [RFE] because bugzilla now styles bugs with 'enhancement' severity in
italics so they stand out easily in bug lists.
Changing Platform to 'All' as Linux is on multiple platforms.
Changing component to "Cmd line features".

The difference between this and bug 104204 is that 104204 is for All platforms.
This bug is about implementing UNIX xremote support for the feature. xremote is
where a mozilla command line passes a command to an already running Mozilla
process. In Win32 running mozilla.exe again automatically launches a new window
in the same process, in UNIX it starts a new process by default.
Blocks: 104204
Component: Browser-General → XP Apps: Cmd-line Features
Ever confirmed: true
Hardware: PC → All
Summary: [RFE] Implement -remote openURL(URL, new-tab) → Implement -remote openURL(URL, new-tab)
Assignee: asa → blizzard
Component: XP Apps: Cmd-line Features → XP Miscellany
QA Contact: doronr → sairuh
Component: XP Miscellany → X-remote
QA Contact: sairuh → blizzard
*** Bug 117757 has been marked as a duplicate of this bug. ***
*** Bug 118972 has been marked as a duplicate of this bug. ***
Hyatt, tell me if I'm off base in how to implement this:

o Find a recently used browser window.
o Set up a JS arg list with the URL as the argument
o Make the call into browser.addTab()

Sound good?
Like bug 104204 and bug 105409, I think this should be fixed by having a pref to
"Open tabs instead of windows for... desktop shortcuts and links in other
applications".  It doesn't make sense to me for another app to decide whether
you prefer to use windows or tabs, or for another app to have an option for
whether it opens new windows or tabs when it opens URLs in Mozilla.

See also bug 99945, "add preference to control if openurl() opens a new window
or not" (reusing browser windows vs opening new browser windows).  That bug
shows an example of someone hardcoding "new-window" into a script when it would
probably be better to allow Mozilla to decide whether to reuse an existing
window based on the user's preferences.
Depends on: 127685
*** Bug 130832 has been marked as a duplicate of this bug. ***
Blocks: 143931
Actually it could be very useful for some other program to decide wether i wanna
open a new window or a new tab. E.g. if I mark some URL and klipper pops up, i
could choose between "Open in Mozilla", "Open in Mozilla (new window)" and "Open
in Mozilla (new tab)". This would be very useful.

Also, if you mean it isn't useful, why is there this possibility "new-window" in
"-remote (URL, new-window)" at all? Let's decide only per preference-base wether
new-window, new-tab or same window/tab, and only open URLs in the exact same
manner forever?! Think this wouldn't be that outstanding...

What about opening URLs in 4 ways:

-remote (URL) -> open in current window/tab
-remote (URL, new-window) -> open new window
-remote (URL, new-tab) -> open new tab
-remote (URL, new) -> open new tab _or_ window, acting upon one pref in the

This appears to be a duplicate of bug 114406 which is a duplicate of bug 104204.
Which is pretty odd, because this bug blocks bug 104204.
No longer blocks: 143931
bug 114406 is not a duplicate of bug 104204, thought it is a duplicate of this
bug.  This bug has to do with unix implementation of 104204 specifically, which
is why it blocks 104204
Comment #9 seems to be a good approach.  The only addition I would make is:
some users don't give a rat's ass what another application (or site) designer
wants and would prefer to always have the pages loaded one way or another.  It
might be necessary to have a preference for remote requests which can be toggled
"tab" | "whatever the other guy intended" | "new window" | "current window"
One question that I have (for my own clarification) is: do other apps invoke the
browser (essentially) through the -remote call?  If not then perhaps the
behavior prefs for commandline "-remote" and other invokations should be
sepearted. (Always do what remote says, other wise put it in a new tab.)
I only see a problem: if you have several windows opened, and that you open a
page in a new tab, to which window the tab will be added?

maybe it should use the window, that would be used if one opens a page _in the
same window_ with "mozilla -remote (URL)", and open a new tab in that window ?
(should be the last focused window?)
I have a patch.  It makes "new-tab" work, in a manner very much analogous to the
"new-window" behaviour we have loved and feared since 2.x, but it doesn't add
any of the other blue-sky items in this bug.  You might want to move the
conversation to another bug, perhaps entitled "more user control over
new-window/new-tab xremote behaviour", because this puppy's going to be closed RSN.
Assignee: blizzard → shaver
Target Milestone: --- → mozilla1.1beta
I use the observer-notify mechanism that jag and I talked about.  At some
point, we'll want to have an nsIBrowserTabControl interface, and it will shine
and sing and dance, but for now this is the least invasive way to get new-tab
working.  It's pretty clean, quite minimal, and -- most importantly, perhaps --

I've only tested on the trunk, but it should work on the branch as well, I
This is a reminder to myself to add a note about new-tab to, once we know which versions this patch
will be present in.  Thanks, biesi.
Blizzard points out that we need to make sure that we honour aOpenBrowser, so
that we don't get a new tab for openURL(,new-tab).

The difference between this patch and the previous is just replacing line 698's

+  else if (newTab) {
+  else if (newTab && aOpenBrowser) {
Comment on attachment 87954 [details] [diff] [review]
Honour aOpenBrowser for new-tab case as well.

Attachment #87954 - Flags: review+
Comment on attachment 87950 [details] [diff] [review]
Read my lips: no new interfaces!

Attachment #87950 - Flags: superreview+
Fixed.  When I get back from Ottawa on Thursday, I'll propose this for the
branch, barring any late-breaking, uh, breaking.
Closed: 22 years ago
Resolution: --- → FIXED
-  const service =
-    Components.classes[";1"].getService();
+  const service = Components.classes[";1"]
+    .getService(Components.interfaces.nsIObserverService);

I'm going to check that in shortly, because at least one person was reporting an
error calling service.addObserver, and it doesn't seem that the observer service
provides nsIClassInfo.  I have sr=jag and r=blizzard.
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.
Keywords: mozilla1.0.1+
Attachment #87954 - Flags: approval+
Checked into the 1.0 branch.
*** Bug 107429 has been marked as a duplicate of this bug. ***
*** Bug 169350 has been marked as a duplicate of this bug. ***
*** Bug 201431 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.