116653 - Implement -remote openURL(URL, new-tab)

Status: RESOLVED FIXED

(Core Graveyard :: X-remote, enhancement)

Description

[pajor]

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

Comment 1

[David Illsley]

Looks similar to bug 104204 but I don't know the exact meaning of -remote.

Comment 2

[David Hallowell]

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.

Comment 3

[timeless]

.

Comment 4

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 117757 has been marked as a duplicate of this bug. ***

Comment 5

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 118972 has been marked as a duplicate of this bug. ***

Comment 6

[Christopher Blizzard (:blizzard)]

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?

Comment 7

[Jesse Ruderman]

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.

Comment 8

[R.K.Aa.]

*** Bug 130832 has been marked as a duplicate of this bug. ***

Comment 9

[Lars Volkhardt]

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
preferences

?

Comment 10

[Anthony DeRobertis]

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.

Comment 11

[pajor]

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 12

[Kirk Kelsey]

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

Comment 13

[Jerome Lacoste]

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?

Comment 14

[Lars Volkhardt]

@Jarome:

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?)

Comment 15

[Mike Shaver (:shaver emeritus)]

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.

Comment 16

[Mike Shaver (:shaver emeritus)]

Attachment: Read my lips: no new interfaces!

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

I've only tested on the trunk, but it should work on the branch as well, I
believe.

Comment 17

[Mike Shaver (:shaver emeritus)]

This is a reminder to myself to add a note about new-tab to
http://www.mozilla.org/unix/remote.html, once we know which versions this patch
will be present in.  Thanks, biesi.

Comment 18

[Mike Shaver (:shaver emeritus)]

Attachment: Honour aOpenBrowser for new-tab case as well.

Blizzard points out that we need to make sure that we honour aOpenBrowser, so
that we don't get a new tab for openURL(mailto:[e-mail],new-tab).

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

+  else if (newTab) {
with
+  else if (newTab && aOpenBrowser) {

Comment 19

[Christopher Blizzard (:blizzard)]

Comment on attachment 87954 [details] [diff] [review]
Honour aOpenBrowser for new-tab case as well.

r=blizzard

Comment 20

[jag (Peter Annema)]

Comment on attachment 87950 [details] [diff] [review]
Read my lips: no new interfaces!

r=/sr=jag

Comment 21

[Mike Shaver (:shaver emeritus)]

Fixed.  When I get back from Ottawa on Thursday, I'll propose this for the
branch, barring any late-breaking, uh, breaking.

Comment 22

[Mike Shaver (:shaver emeritus)]

-  const service =
-    Components.classes["@mozilla.org/observer-service;1"].getService();
+  const service = Components.classes["@mozilla.org/observer-service;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.

Comment 23

[Judson Valeski]

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.

Comment 24

[Christopher Blizzard (:blizzard)]

Checked into the 1.0 branch.

Comment 25

[Boris Zbarsky [:bzbarsky]]

*** Bug 107429 has been marked as a duplicate of this bug. ***

Comment 26

[R.K.Aa.]

*** Bug 169350 has been marked as a duplicate of this bug. ***

Comment 27

[Boris Zbarsky [:bzbarsky]]

*** Bug 201431 has been marked as a duplicate of this bug. ***