Closed
Bug 74987
Opened 24 years ago
Closed 24 years ago
Specifying an invalid URL using OpenURL via x-remote should display error message.
Categories
(Core Graveyard :: X-remote, defect)
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.
Comment 1•24 years ago
|
||
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
Updated•24 years ago
|
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.
| Reporter | ||
Comment 3•24 years ago
|
||
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.
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
Comment 8•24 years ago
|
||
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: 24 years ago
Resolution: --- → WORKSFORME
-> x-remote
Component: Networking → X-remote
QA Contact: benc → blizzard
Updated•20 years ago
|
No longer depends on: errorpages
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•