when using X-remote OpenURL() can not load a url in the current window

VERIFIED FIXED in mozilla0.9.1

Status

()

P3
critical
VERIFIED FIXED
19 years ago
17 years ago

People

(Reporter: blizzard, Assigned: blizzard)

Tracking

({regression})

Trunk
mozilla0.9.1
x86
Linux
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: critical for mozilla 0.9.1)

Attachments

(3 attachments)

(Assignee)

Description

19 years ago
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.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 1

19 years ago
Created attachment 19053 [details] [diff] [review]
[patch] Go away, appCore. This should make open location behave better

Comment 2

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

Comment 3

18 years ago
over to jag for a look
Assignee: blizzard → disttsc
Status: ASSIGNED → NEW

Comment 4

18 years ago
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.

Comment 5

18 years ago
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. 
Keywords: regression

Comment 6

18 years ago
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?

Comment 8

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

Comment 9

18 years ago
Mass move to jaggernaut@netscape.com
Assignee: jag → jaggernaut

Comment 10

18 years ago
->blizzard per jag
(Assignee)

Comment 11

18 years ago
*** Bug 82969 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

18 years ago
Severity: normal → critical
Status: NEW → ASSIGNED
Whiteboard: critical for mozilla 0.9.1
Target Milestone: --- → mozilla0.9.1

Updated

18 years ago
Assignee: jaggernaut → blizzard
Status: ASSIGNED → NEW
Over to blizzard for real now.
(Assignee)

Comment 14

18 years ago
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.
(Assignee)

Comment 15

18 years ago
Created attachment 37033 [details] [diff] [review]
patch after dbaron's offline comments
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.)
(Assignee)

Comment 17

18 years ago
> 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.

Comment 19

18 years ago
sr=tor

Updated

18 years ago
Blocks: 83989
a= asa@mozilla.org for checkin to the 0.9.1 branch and the trunk.
(on behalf of drivers)
(Assignee)

Comment 21

18 years ago
Checked in.  Thanks, guys.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 22

18 years ago
  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).
(Assignee)

Comment 23

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

Comment 24

18 years ago
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

Updated

17 years ago
Component: XP Toolkit/Widgets → X-remote
You need to log in before you can comment on or make changes to this bug.