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.
Created attachment 19053 [details] [diff] [review] [patch] Go away, appCore. This should make open location behave better
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
Assignee: blizzard → disttsc
Status: ASSIGNED → NEW
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 firstname.lastname@example.org
Assignee: jag → jaggernaut
->blizzard per jag
*** Bug 82969 has been marked as a duplicate of this bug. ***
Severity: normal → critical
Status: NEW → ASSIGNED
Whiteboard: critical for mozilla 0.9.1
Target Milestone: --- → mozilla0.9.1
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.
a= email@example.com for checkin to the 0.9.1 branch and the trunk. (on behalf of drivers)
Checked in. Thanks, guys.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.