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)
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•23 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•23 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•23 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•23 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: 23 years ago
Resolution: --- → WORKSFORME
-> x-remote
Component: Networking → X-remote
QA Contact: benc → blizzard
Updated•19 years ago
|
No longer depends on: errorpages
Updated•5 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•