Closed Bug 74987 Opened 23 years ago Closed 23 years ago

Specifying an invalid URL using OpenURL via x-remote should display error message.

Categories

(Core Graveyard :: X-remote, defect)

x86
Linux
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED WORKSFORME
Future

People

(Reporter: scarney, Assigned: neeti)

Details

When using x-remote to open a URL, specifiying an invalid url will not return
any information that the url has failed load.

Example:
With a running Mozilla window, run the following:

./x-remote -d :0 -remote "openurl(www.sun.coo)"

This will not display the "Unable to locate site www.sun.coo" message like it
should. This is how it functioned in Netscape 4.*.

As an enhancement I think you should be able to turn this feature off to make it
act like it does currently.
over to netwroking.  cc'ing blizzard in case he's interested.
Assignee: asa → neeti
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking
Ever confirmed: true
QA Contact: doronr → tever
Target Milestone: --- → Future
Depends on: errorpages
(I'm testing with mozilla's -remote option instead of "x-remote", which I don't
have.)

Actually, openURL(FOO) will do nothing in any case, regardless of FOO being
valid or not. openURL(FOO,new-window) works, and displays the not-found dialog
when FOO is something like "www.sun.coo".

So I think this is really a dupe of 41527.
What build are you testing on? I will retest tomorrow with 0.9 and the latest 
nightly build but as of 0.8 this bug was valid. Specifying 'openURL
(www.sun.com)' would load a the URL in the current window and specifying an 
invalid window would do nothing 'openURL(www.sun.com)'.

Like I said I will retest on May 22nd and post here.
You are right, I can reproduce this problem on an Apr 2 build. But newer ones
can't be tested reliably - we have to wait on the resolution of bug 41527 for that.

(Does that make 41527 a dependency? I don't think so.)

Note that openURL(www.sun.coo,new-window) will bring up a new window and an
error dialog (i.e. behaves as expected) on the Apr 2 build, and on a build from
yesterday.
mass move, v2.
qa to me.
QA Contact: tever → benc
Bug 41527 is fixed now, so this one is testable again. Not magically gone,
though.

IOW,
  mozilla -remote 'openURL(http://host.invalid/)'
is still ignored without any errors, while
  mozilla -remote 'openURL(http://mozilla.org/)'
works.

(On today's branch build)
Can someone give me more background on what is going on here?
Keywords: qawanted
Just tried it in Mozilla-0.9.7 (ftp.mozilla.org rh7 binary RPMs) on RedHat Linux
7.2 and I did get the correct error message.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
-> x-remote
Component: Networking → X-remote
QA Contact: benc → blizzard
No longer depends on: errorpages
Keywords: qawanted
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.