we really should implement x-remote in 5.0 http://home.netscape.com/newsref/std/x-remote.html logging bug to get this on the radar.

Updating QA Contact to a Unix tester.

adding akkana.

Believe it or not, x-remote support is out. But now that mcafee is joining XPApps, we may have the resources to do this post dogfood beta.

I believe that it's out: there is a ton to do and not enough time to do it. maybe add this to the [HELP WANTED] list? I'm sure there are bigger fish to fry than x-remote. if enough people miss it, it will come back.

Putting it on the HELP WANTED list sounds good. I know I'll miss it quite a bit, and it sounds like something that would be fairly easy for an outsider to add (shouldn't involve going deep into the guts of xpcom or anything like that). Especially if the outsider could browse the Classic code to see how it was done in the old codebase.

We've GOT to get someone from KDE/GNOME to work on this then... currently GNOME supports, and defaults to, opening URLs in Netscape via x-remote.... I don't know anything about X-remote or how it works, but I do know this has to be in RTM or we won't have a viable browser for the Linux desktop....

Updating QA Contact

Not required (ouch!) for beta 1. Sometimes I just hate myself ...

Not having this be a beta-1 requirement strikes me as though it will significantly cut down on the use (and therefore bug reports) that come out of beta-1. A large percentage of browser use comes from clicking on URLs in other applications (eg irc client, newsreader, mailer). If it's not possible to do this, many people are likely to just keep using netscape for all that browsing. Any chance of reconsidering this?

Agreed; a lot of people will end up using their old browser simply because of clicking on a link in some other app. I find myself doing that fairly frequently even when I'm trying to use mozilla, and then sometimes saying "Oh, well, now that I have a 4.x up anyway, I'll just use that since it's so much faster/easier ..." :-(

adding shaver and blizzard, since you aren't a real X head if you aren't CC'd on this bug. adding http://lxr.mozilla.org/classic/source/cmd/xfe/remote-s.c and http://lxr.mozilla.org/classic/source/cmd/xfe/remote.c for reference. I'll also post to n.p.m.unix to see if anyone is interested in helping.

reassigning to me.

You knew I was going to say this, but I think the right thing to do is define an nsIRemoteBrowserControl interface, and we can implement it first using the 4.x X-properties hack. Later, people can add implementations to use CORBA or DCOM or whatever turns them on.

Also including as a reference: http://home.netscape.com/newsref/std/x-remote.html and: http://home.netscape.com/newsref/std/remote.c

Agreeing with shaver. Backwards compat. with 4.x would be nice, at least for URL-level stuff, but not mandatory.

We might want to work with the embedding folks (Travis) to see if we can either combine APIs or at least make the look & feel of the API very similar, since they have to do similar stuff like loading URLs

I'm evaluating the 4.x implimentation and other docs in this bug now and will propose a possible solution for discussion soon. If Pav doesn't mind I'll takeover the bug.

sure, you can take it if you'd like :)

Taking over the bug now.

Initial Impressions and Questions: I've spent a few hours looking at good ways to implement Xremote and reviewing Jamie's 4.x code and here is what I've come up with so far. 1) Take Shaver's advice and create a nsIBrowserControl interface and it's associated X-specific factory to start out with. 2) It should include as many of the original 4.x options as possible so that it's backwards compatible. I plan to keep the original -remote command-line options intact as well as the -id, -raise, and -noraise options. 3) Create a new autoconf option --with-xremote to hide platform specific nature of this component. Initial Questions: 1) Where is the most appropriate place to land this? /mozilla/xpfe/components/xremote maybe? Which module should it be incorporated into? 2) What's the best way to add the new command line options to /mozilla/xpfe/bootstrap/nsApprunner.cpp without having a bunch of ifdefs? I know this is very bad way to do it but I'll need additional command-line parsing and options specific to xremote to make it work like the original implementation. 3) Are there any gtk widget dialogs which I can use/leverage from to get the necessary openURL / openFile popup? I'm still looking through the mozilla source to find all the classes for the necessary calls. I've found several useful ones but I'm still missing a few. I've also started writing the inital design spec up for approval. This will be posted once I collect all the missing pieces.

The service component itself should probably be a component. However, the code to access that service is going to be in the platform specific widget code for each of the platforms. Something like this: #include "nsISupports.idl" interface nsIRemoteBrowserControl : nsISupports { /* setting newWindow to true will create a new window. if url is null, a dialog will ask for the url to open. */ openURL(in string url, in boolean newWindow); /* comma seperated list of addresses to mail to */ mailto(in string mailtoList); /* this will add a bookmark. if URL is null, it will add the current page. if the title is not null it will use that for the title in the bookmark. */ addBookMark(in string URL, in string title); } The widget specific code should receive the message and call the service.

concerning the command line arguments, I own the bug for implementing a way for components to register that they handle arbitrary arguments. see http://scopus/bugsplat/show_bug.cgi?id=368159

*cough* Can't seem to get to that url. *cough* ( why is that a bugsplat bug? )

I don't understand the rationale for adding an autoconf option for this. Shouldn't it always be compiled when using an X-based toolkit? Is there some situation in which one would want to turn it off?

I agree, no need to make it an autoconf option, since this isn't something that's going to break the main product. I'm going to file a new bug, against sspitzer, for the general command line problem. sspitzer's bugsplat bug is about a certain product which will go unnamed here.

bug 24870 has been filed. Add yourself to the CC if you're interested.

I've created the first proposed Interface idl file and attached it to the bug. Its pretty crude right now and I'm not an xpIDL or xpCOM guru so have a look and let me know if I've done something foolish. I wasn't sure if it should be scriptable or not so I made it scriptable for now. You'll notice that only one of the original remote options is not included. I did not include the original saveAs(Output-File, Type) since this should be handled by the Save As dialog. If anyone thinks it should be there let me know. Right now I plan to land the interface in xpfe/components/xremote directory once everything is done. There may be additional files landed in the widets stuff but that's TBD. Once I get the complete interface written I'd like to get someone to review it before I move on to the x implementation.

Don't call it xremote, it should be more generic if it's living in xpfe/components. remote? moz-remote?

What about something as simple as this in stead: interface nsIRemoteBrowserControl : nsISupports { void executeCommand(in string aCommand); }; This way we wouldn't tie the commands we can support to a putlic interface. Adding support for more -remote commands would just be a matter of updating the component that implements this interface without changing the interface. With an interface like this we could pass the complete -remote argument to the "remote" component and let the component take care of the -remote argument parsing, then we could simply do: aRmtBrowserCtrl->ExecuteCommand("addBookmark(\"http://foo.bar\", \"title\")"); Comments?

two things before we go any further: - isn't there a DDE or remote interface for windows as well... yep, just found this on devedge: http://developer.netscape.com:80/docs/manuals/communicator/OLE/index.htm Specifically, the Netscape.Network.1 OLE automation interface looks promising. I believe IE implements some of these as well, and in fact there is an MIDL idl file in the OLE reference... since X-remote is kind of a legacy X-remote-control system, maybe we want to see if we can converge on legacy interfaces with this

BTW, I really disagree with the executeCommand() technique.. one of the reasons we use interfaces is that they don't change, they are a contract between objects. executeCommand() essentially hiding the interface behind a string, making it so that it could change so that code like browser->executeCommand("openURL(http://mozilla.org/);") could change behavior from release to release. This is bad. if we want to add a bookmarks-controlling interface, then we create a new interface, and maybe a new service behind it too.

I'm not sure if the windows stuff is relavent to the scope of this particular bug but correct me if I'm wrong. My current design intentions are to mirror the original xremote features in 4.x. That's pretty much where I'm drawing interface design criteria from. I will also add the x specific implementation afterwards. Hopefully, the interface will be generic enough for future platform specific implementations like windows or dce or whatever. Most of the outsiders would like to use xremote in the same manner that they do it with 4.x. I like Mcafee's idea about a generic executeCommand but this will most likely be related to sspitzer's Commercial Bug #368159 mentioned above for the command line parsing of arbitrary arguments in apprunner. I believe this is still be hashed out but will eventually impact this feature. I'll start worrying about the command line options and how to implement them after we get a solid base interface in place. My 2 cents....

Sorry it wasn't mcafee it was jst ....

BTW - per mcafee I'll land the interface in xpfe/components/remote so that it's sufficiently generic. Let's get the interface generic enough to suit any particular implementation. As always, I'm open to suggestions about missing or unneeded parts of the interface to make this happen.

alecf, I'm cool with peppers interface but you say that one of the reasons we use interfaces is that they don't change, that's true and because of that, putting the different supported commands in the interface makes the -remote fuctionality _unextendable_. And, defining openURL() in the interface doesn't mean that the behavior can't change from release to release. Also, addBookmark() wasn't something I made up or something I'd like to add, I got that from the -remote spec mentioned above. I imagine that lots of people might want to extend the -remote "command set" if it's easy enough to do, and using executeCommand() would make this really easy, if you'd want to support "-remote 'doThatThingYouDoSoWell(now)'" you'd only need to extend the component that implements the -remote stuff, without recompiling any callers (possibly unaccessible Netscape owned code)... Either way is ok with me but I making -remote _unextendable_ doesn't make much sense to mee...

I think we're confusing unextendable interfaces vs. browser remote command lines. The interface is something you call from C++ or JS The xremote command line is a string that gets parsed and turned into a call on one of these interfaces. Eventually the x-remote command parser will call SOME interface on SOME service, so we might as well make that interface well defined. When you need to extend it, we either add another service, or another interface on the same service.

Yes, seems like we are, and it seems like my ideas of the xremote component boundaries are different from everybody elses... I still however think that having a generic interface to execute commands in an allready running mozilla process would be worth having, this way if someone wants to add a new command they won't have to code the IPC in order to do this and this whole -remote thing could then be build on top of this...

The problem with generic interface is that when applications try to use it they never know what version they are using and what the results of a particular action will be. alecf eluded to this as part of the "contract" between the consumer of the interface ( your client program ) and the implementation of the interface ( mozilla ). If we want to add more capabilities later, we should add another interface to do that. nsIRemoteBrowserControl2 or something. That we we always provide a known interface to clients and we can always provide a backwards compatible interface.

New summary, X-remote should really be XP-remote per the XP discussion here. :-)

Changing the target milestone to M16 since the command line options needed won't be in place until then. See Bug #24870 for more info.

I thought this bug was just there to support some old unixy behaviour? Why is it XP all of a sudden? It looks like we are talking about three seperate things that we are talking about in this bug. o What the internal interface should look like o The command line interface o The actual X protocol implementation The command line interface looks like it depends on another bug but we can still design the interface and write the X protocol implementation.

I agree blizzard. I signed on to write the X specific implementation of the remote feature, originally a very well defined feature. I plan to continue hacking on the interface and the X implementation but the Feature won't land and cannot really be tested until I can pass arguments with the -remote command line. I'll most likely hack apprunner.cpp locally to do preliminary testing but noone else will see this until apprunner allows feature specific command line arguments. I would like the interface to be generic enough for others to add whatever remote implementation they want but my primary concern is XRemote.

Ok back to old summary. Sorry for the confusion, I hope we can get an XP interface out of this though.

So this latest flurry of comments started off with the idea that not having -remote in beta would hurt the amount of testing that beta gets. Given the M16 comment, is the hope of getting this in sooner doomed?

Its very unlikely that this will make it into M14. Twelve days isn't very much time to make this happen... I'll do everything I can to get the xremote implementation written but I'm totally dependant on sspitzer's command line options bug to land it. He set his bug to M16, therefore I did the same. I have no idea how high up this bug is on his list. If everyone is reasonably happy with the interface I proposed, I'll get back to coding. I was giving everyone a chance to get their opinion in on the interface now since it will most likely be used for other things besides xremote in the future.

then I better get my ass in gear. I'll try to something working for you soon.

No guts no glory. I'm putting it on the radar for the M14 beta. All you porkjockies on the CC list should vote for this bug in the next review if you think its a must. I'll see how much of it I can get written this weekend. I dunno if I'll make it but I'm going to give it my best shot.

I'm working on the arbitrary command handling now. I hope to be able to have what pepper need working today.

Due to Beta indication in Summary, putting beta1 into keyword field.

Putting on PDT- radar for beta1.

The generic interface has landed in mozilla/xpfe/components/remote. It is not hooked up to the core build yet. I talked to sspitzer for a while tonight and he has a novel approach to the generic implementation which I did not consider. He will probably land a js implementation soon which will handle the command line calls + the generic interface implementation. I'm working on a c++ wrapper now to Jamie's original xremote implementation. Many thanks to Seth who has been a tremendous help in making this happen.

It looks like Seth has gotten alot of very valuable work done on this tonight. The generic interface will probably be turned on in the core builds tonight with alot of the generic remote functionality in place. I'll be adding more of the the missing implementation details tomorrow. It's looking very likely that this feature will make it into the M14 Milestone. I wouldn't have made M14 without you man!

OK - Sorry folks but I'm not sure that targeting this for M14 is the right thing to do this late in the game. It is not considered a PDT+ bug and I certainly don't want to destabilize the tree when we are so close to beta. PDT+ bugs ake precedence right now. This does not mean that I won't be working on it. I will continue working on the functionality and if it looks really clean and stable and I get checkin approval it may still land in time for M14. I'll keep you posted on the progress.

sorry for the spam

Well, this friday will be my last day at netscape, but I plan to continue contibuting to mozilla and finishing this feature. I haven't got to work on it as much I would have liked recently since I've been swamped with finishing up some things for my pending departure. Once I get settled into my new job on Monday, I'll start working on this again. Sorry its taking so long.

Taking ownership of this since pepper is leaving.

mozilla/xpfe/components/remote/src/remoteControl.js has suffered some bit rot, as the command line handling has changed underneath it. I'll whip it back into submission today.

Moving out...

Please ignore the spam. Changing address.

busted from my reassign

where do we stand on this? nothing but spam for quite a while...

I think that people are all working on other things for the time being.

when we ever do find time for this (which won't be soon), we can implement the command line handling part pretty easy now that I've done it once for chatzilla. see mozilla/extensions/irc/js/lib/chatzilla-service.js We'll have to do some copy & paste into mozilla/xpfe/components/remote/src/remoteControl.js

I've started writing code for the X part of this.

Ok, the server side of this code is pretty much done. I need the generic parser that seth and I talked about offline done, though. Also, I need to know what to do about the client bit. It's not as straight forward as it seems since it needs to fallback to actually starting up the browser. Maybe it's enough to create a new |nsIAppShell|, do everything I need to to start it up and run a special service that knows how to try to activate an already running instance. However, that causes problems because it means that we have two instances of mozilla running which might cause problems and other things I can't remember at 1 in the morning.

yeah, i we used the current command line handling code, "-remote 'foobar'" would get handled too late, and we'd have started up two instances. because of the special nature of -remote, how about this: see HandleDumpArguments() in nsAppRunner.cpp we handle (or will handle) -v and -h at that point, and then exit. we could add -remote support there. if we determine there is "server" instance running, we send the events to the "server" instance and then exit. if there isn't a "server" instance running, we contiue on and we have a typical command line handler handle "-remote 'foobar'" and do the right thing. or, we could forget about having a typical command line handler for -remote, and in main() in nsAppRunner.cpp, if we fail to find a running "server" instance, we convert argv & argc (that has -remote) into an argv & argc that will have the same result. mozilla -remote 'mailto' -> mozilla -compose

profiles throw a bit of a monkey wrench into X remote. we would not want to send commands to a mozilla instance if it was in the profile manager. how did we handle this in 4.x on win32? (there was no profile manager on unix in 4.x) i guess it is not that big of a deal, but something to think about.

If there's no existing server instance, the traditional behavior of Unix NS 4.xx (and I think all versions since -remote came in) is to print a message and exit with status 1. I personally think that this is a decent behavior to preserve, and easy to boot. (Besides, scripts are going to count on this; they may not expect their 'mozilla -remote' invocations to potentially hang around for a long time.)

The point at which we do communication to find out whether or not there's an already open window and to do the activation is not exactly XP. I'm still not sure what to do about that. The server side also isn't XP. On Unix it's powered by the window toolkit. What about the Mac and Windows? Does anyone know?

First pass at the server side code. Waiting on waterson/brendan for approval to check it in. r=shaver on this code.

- Use doc comments /** */ in the .idl file for more righteous doxygen'ing -- even better if you document each methods params, results, etc. with javadoc tags. - Bugs near JS_PushArguments call: // make sure that we pass a valid name even if there isn't one // passed in. const PRUnichar *name; const PRUnichar *url; static PRUnichar kEmpty[] = { PRUnichar(0) }; name = aName ? aName : kEmpty; aURL = aURL ? aURL : kEmpty; jsval *jsargv; void *mark; jsargv = JS_PushArguments(jsContext, &mark, "sssW", aChromeURL, name, aWindowFeatures, url); url is used but not set (aURL is wrongly re-set, I think). Name is a PRUnichar* so its format should be W, not s (just as url's format is W). Right? I didn't give a detailed review to the X-specific stuff, but if you fix the above, go ahead (a=brendan). /be

I fixed that. Good catch, brendan. Checked in. If there's stuff missing we should file RFEs to fix the individual issues.

vrfy fixed using 2001.02.09.08 comm bits on linux. 1. launched netscape 2. in another shell, entered: ./netscape -remote 'openURL(http://www.kith.org)' result: http://www.kith.org is loaded into the existing browser window.