When using OpenURL() via X-remote the open location dialog never has "Use Current Window" selected. The open location routines need the nsIBrowserInstance object. You can't get that object from C++ given a specific nsIDOMWindow.

This is related to bug 36208. I'll go play with x-remote today to see if this actually works ;-)

over to jag for a look

On an Apr 02 build: "mozilla -remote 'openURL(http://www.mozilla.org/)' works. On a recent build: nothing happens => regression [some wizard set the keyword please, I'm not empowered] Appending ",new-window" will open a new window and load the URL in both versions.

Build Id 2001051815 on RedHat Linux 7.1 - not just "nothing happens", but I actually get Failed to send command. error message if I try to openurl without new-window.

bug 83092 is a duplicate of this one (but marked critical & targeted mozilla0.9.1, so I do not want to be the one to resolve it as a duplicate).

Bug 83092 doesn't look related to this at all. Is that really the bug number you meant to type?

Oups! Pasted the wrong number. I meant bug 82969, sorry about that.

Mass move to jaggernaut@netscape.com

->blizzard per jag

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

Over to blizzard for real now.

The bug was that nsIURIContentListener wasn't in the list of supported interfaces for the content listener object that I was passing to the URI loader. Duh. Easy fix. o I also changed IsPreferred to just return NS_OK since it's called now but we don't really care about content types from that loader. o Removed a tab in front of the call to OpenURL(). o Make sure to pass errors from the URL loader back to the caller so the error can be reported to the person making the X remote call. Looking for review/super-review.

You don't need the semicolon after the NS_IMPL_ISUPPORTS2 macro. :-) > o I also changed IsPreferred to just return NS_OK since it's called now but we > don't really care about content types from that loader. Do you need to null / set to true/false any of the out params? > o Make sure to pass errors from the URL loader back to the caller so the error > can be reported to the person making the X remote call. Maybe you want to propagate the error returned rather than NS_ERROR_FAILURE? And should it be an assertion if there's a failure? (NS_ENSURE_* macros assert and return, IIRC.)

> You don't need the semicolon after the NS_IMPL_ISUPPORTS2 macro. :-) > Fixed. > > Do you need to null / set to true/false any of the out params? > I thought that I would let the caller's defaults stand. In this case the caller is the URI loader which will find a viewer for the specific kind of content and that's exactly the behaviour that I want. > > Maybe you want to propagate the error returned rather than NS_ERROR_FAILURE? > And should it be an assertion if there's a failure? (NS_ENSURE_* macros assert > and return, IIRC.) > It's all inside the remote helper class. The only error that I'm returning is some kind of failure so I just remap all calls. It's consistent with the other returns in the function.

ok, r=dbaron

sr=tor

a= asa@mozilla.org for checkin to the 0.9.1 branch and the trunk. (on behalf of drivers)

Checked in. Thanks, guys.

mozilla -remote 'openURL(http://mozilla.org/)' works again. Good. mozilla -remote 'openURL(mozilla.org)' however, does not work. I think it did before this bug arose. With ",new-window", both alternatives work (as always).

The second one sounds like a seperate problem. Please open a new bug about it.

verified fixed, branch and trunk 06/05 builds. ./mozilla -remote "openurl(http://www.mozilla.org)" and ./mozilla -remote "openurl(http://www.mozilla.org,new-window)" both work, with the second form opening in a new window. ./mozilla -remote "openurl()" does work, but there is a problem with focus switching back from the autocomplete popup to the launching term window filed bug http://bugzilla.mozilla.org/show_bug.cgi?id=84238 I also filed the above point about "openurl(www.foo.com)" working without the scheme http:// prepended : http://bugzilla.mozilla.org/show_bug.cgi?id=84239