Closed
Bug 8345
Opened 26 years ago
Closed 19 years ago
Smarter user feedback for HTTP errors
Categories
(SeaMonkey :: General, enhancement, P3)
SeaMonkey
General
Tracking
(Not tracked)
Future
People
(Reporter: csbooton, Assigned: bugs)
Details
Ya know how when you type an invalid URL into 4.xx and it says that it cannot located the URL. i think it would be more clear if it said that it cannot be located, followed by "The URL (url entered here) does not appear to exist" , then "Please check it any try again". Perhaps then it could give you if you wanted a list of sites with simular URLS, in hope that one of them is right and you may have spelled it wrong. (for example you type http://www.mozillla.com , it will give you the it doesent exist message then give you http://www.mozilla.com as a possible one that you meant to type in). I guess this list could be give to you via a button on the error message and pressing it would open up a lower part of this box with the list of vaild URL's (in prefrences you could choose ho many to display) and you click on one to try it. and if the url exists but for some reason the site cannot be located instead of saying it does not have a DNS entry (Which I assume means that your ISP has a record saying that the url exists, but it does not know what it IP address is) say that "It's IP address could not be determined, please try again later" And how about if a site is fine but it cannot be reached do to problem somewhere on the internet then an error message that gives the option to do a tracert to see where the problem is, then it could give you the option to e-mail the admin of that problem area to inform them it's messed up. Hopefully this way the error messages could be more usefull and more clear and you could do something about the problem rather then just get anoyed.
Updated•26 years ago
|
Assignee: shuang → german
Comment 1•26 years ago
|
||
Nice thoughts. assign it to german to think about what kind of smart thing we can do...
Rather than client based the solution to this might be server-based, aka smart browsing. I am latering this bug for it to stay on the rear view mirror.
Moving all UE/UI bugs to new component: User Interface: Design Feedback UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
Comment 4•24 years ago
|
||
reopening and marking future, updating QA contact
Status: RESOLVED → REOPENED
QA Contact: mpt
Resolution: LATER → ---
Target Milestone: --- → Future
Comment 5•24 years ago
|
||
[debogosifying summary]
Depends on: errorpages
Hardware: PC → All
Summary: [feature request] → Smarter user feedback for HTTP errors
I agree with the general notion - is the author willing to propose/create a spec? I am forwarding this bug to the mozilla UI owner ben, to see whether he can do something with it
Assignee: german → ben
Status: REOPENED → NEW
Updated•24 years ago
|
QA Contact: mpt → zach
Comment 7•24 years ago
|
||
Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Updated•22 years ago
|
Component: User Interface Design → Networking: HTTP
Comment 8•22 years ago
|
||
Suggestion: Unable to locate $URL Please check the spelling of the address above. If its wrong, simply correct it in the address bar above and [click Go|hit Enter] to try again. If the address looks right, it may be that this is just a temporary problem and you might want to try back later. { if here from clicking a link } If you don't know if the address is right or not, try going back to $PrevURL and E-mailing its maintainer to tell them the link didn't work for you. --- Note: Could easily use the meta tags on the previous site to grab the E-mail address of the maintainer if available and offer the link directly ... being user-friendly isn't bad ;-)
I'm sending this bug to browser-general, because this would not be a feature of the HTTP module. I guess could take the general thrust of the document as app-level docshell feature, but as a single bug, it has too many different ideas for one bug. "page not found" - The HTTP server returns a 404 code as an error -AND- HTML of it's choosing. This is a commonly misunderstood point about HTTP, the server sends back an HTML page w/ the error message. Improvements to this page should be made on a per-server basis. This is well established web-admin perogative, a feature that changes this would be of questionable validity. "if the url exists but for some reason the site cannot be located instead of saying it does not have a DNS entry" - if a site is not in DNS, then, pragmatically, it really does not exist. If a site cannot be found in DNS, in most cases, the URL is wrong, not DNS. Both Internet Keywords and Domain Guessing trap these errors in various situations, so you should look at the existing features and file bugs against them. "it cannot be reached do to problem somewhere on the internet then an error message that gives the option to do a tracert" - We do not report unreachability errors correctly right now, bug 115982. Offering to send the admin a message is usually unecessary (unlike the 80's, people notice pretty immediately when the router is down), and in most cases, email will not arrive for an admins of disconnected networks.
Component: Networking: HTTP → Browser-General
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 11•19 years ago
|
||
*** This bug has been marked as a duplicate of 28586 ***
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 19 years ago
No longer depends on: errorpages
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•