need error handling for bogus URLs

VERIFIED WORKSFORME

Status

SeaMonkey
General
P3
normal
VERIFIED WORKSFORME
19 years ago
13 years ago

People

(Reporter: sujay, Assigned: travis)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

19 years ago
using 11/24 build jump to an illegal URL like above.

nothing happens in NGLayout, we need to spit out a message
like the old 4.x browser:

"Netscape is unable to locate the server:
www.netscape
The server does not have a DNS entry.
Check the server name in the Location(URL) and
try again."

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Assignee: rickg → rpotts
Status: ASSIGNED → NEW

Comment 1

19 years ago
On start binding (in the parser at least) never gets called.
It's probably in your domain or netlib.

Updated

19 years ago
Assignee: rpotts → gagan

Comment 2

19 years ago
Re-assigned to gagan@netscape.com.

Gagan, is this a netlib bug?  Who should get this?

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 3

19 years ago
Setting all current Open/Normal to M4.

Comment 4

19 years ago
setting paulmac as QA contact for all gagan's bugs (sorry for the spam)

Updated

19 years ago
Target Milestone: M4 → M6

Comment 5

19 years ago
Marking till Necko lands...

Comment 6

19 years ago
Per DP's suggestion marking these till M8. Though Necko lands with M7, we will
be able to verify it for M8.

Comment 7

19 years ago
I'm moving this to target M9, Necko will be enabled somewhere during late M8 or
early M9.  We will need to get on this and it cannot be postponed past the M9
milestone.

Updated

19 years ago
Assignee: gagan → rickg
Status: ASSIGNED → NEW

Comment 8

19 years ago
The error is now being pushed out to OnStopRequest (in Necko) the consumers now
need to hook in the response. In general we need to set up an error display
mechanism which reads off from standard lists of Netlib errors. Assigning to
component owner to work this out. (How are other errors being handled now?)

Updated

19 years ago
Assignee: rickg → scc

Comment 9

19 years ago
We don't care whether this shows up in viewer per se. It just needs to be dealt
within AppRunner. Scott -- Since you're now the webshell API owner, I think you
should own this issue. The error needs to get propagated to the APP, where a
dialog can be flown. The parser is already sending error codes out to the caller
when things like this occur, so it should be easily trapped at the docloader
level. Call me if you need additional help.

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Priority: P2 → P3
Target Milestone: M9 → M10

Updated

18 years ago
Target Milestone: M10 → M11

Comment 10

18 years ago
Moving to M11 per today's bug triage.

Updated

18 years ago
Assignee: scc → travis
Status: ASSIGNED → NEW

Comment 11

18 years ago
According to rickg, this bug goes along with the webshell.  Sorry travis.

Updated

18 years ago
Component: Viewer App → Browser-General
OS: Windows 95 → All
QA Contact: paulmac → tever
Hardware: PC → All

Comment 12

18 years ago
*** Bug 11362 has been marked as a duplicate of this bug. ***

Comment 13

18 years ago
m12
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Depends on: 13374

Updated

18 years ago
Summary: need error handling → need error handling for bogus URLs

Comment 14

18 years ago
Move to M13 and re-assess once basic Webshell re-design is complete.

Updated

18 years ago
Target Milestone: M13 → M14

Comment 15

18 years ago
Move to M14.  Is this required for beta 1?

Comment 16

18 years ago
appears to be fixed with a decent dialog in 2000020310 on NT.

Marking fixed.  Please verify.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 17

18 years ago
yes, the error handling is in except on linux I get a blank dialog. 
NT is fine but haven't checked Mac.   Re-opening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 18

18 years ago
Please re-verify.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME

Comment 19

18 years ago
verified:
NT 2000042009
Linux 2000042509
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.