Open Bug 229690 Opened 21 years ago Updated 2 years ago

JavaScript can not override the File-Not-Found alert

Categories

(Core :: DOM: Navigation, defect)

defect

Tracking

()

People

(Reporter: wbailey, Unassigned)

Details

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

Comment #31 From Simon Fraser 2001-09-04 regarding Bug #63048 sums up the 
problem.

"It seems very wrong to me to be posing 'file not found' dialogs from webshell 
code. I think putting up dialogs should be the responsibility of something 
higher up the chain, like navigator's JS (assuming an appropriate error can be 
passed up). A good reason why posing dialogs here is bad is that embedders 
might want to alter this behaviour (e.g. do the IE-style errors-as-web-page 
thing), or might have a situation where missing files is a benign and 
ignorable error."

The "file not found" alert is issued before JavaScript code can intercept and 
handle the error. In my case, these alerts are not only unnecessary, they 
prohibit a clean implementation of an otherwise simple algorithm. This is also 
inconsistent with the way image load errors are handled in JS. 


Reproducible: Always

Steps to Reproduce:
1.Execute the JavaScript in the "Additional Information" section with or 
without uncommenting the try/catch code.
2.
3.

Actual Results:  
An standard alert box issued by the browser appears. After it's been dismissed 
the alert issued by the JavaScript appears. 

Expected Results:  
Should see only the alert issued by the JavaScript

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
     PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <title> Main Map </title>
    <script language = "JavaScript" type="text/JavaScript">

/* The File-Not-Found alert issued by the Mozilla Browser can not
   be intercepted by either an error handler or a try/catch */

     window.onerror = badLink;

     function badLink() {
     alert("JavaScript: Handled Bad Link" );
     return true
     }

     document.onkeydown = keyPressed;

     function keyPressed(evt){

       if (evt.keyCode == 13) {
//         try {
           window.location = "NoSuchFile.html";
           window.location.reload();
//         }      
//         catch(e) {
//           alert("JavaScript: Caught Bad Link");
//         }
       }
    }

    </script>

  </head>

  <body>
    Press ENTER
  </body>
</html>
Not a networking issue; necko is not posting the dialog.

At the moment, the error pages impl lives in docshell too.  Perhaps what we need
is for embeddors to hook up an "error listener" to the docshell?  docshell could
report errors to this and the error listener could decide what to do?  So all
the code currently living in webshell that handles errors could move out into
embedding clients....
Assignee: darin → adamlock
Status: UNCONFIRMED → NEW
Component: Networking: File → Embedding: Docshell
Ever confirmed: true
QA Contact: benc → adamlock
is comment 0 referring to web pages wanting to intercept the file not found
dialog, or about embedding applications?
Embedding apps, I would assume.  Which is why I totally ignored the testcase
included in the comment, since there is no way that should work.  But embedding
apps really do need a way to control how the error reporting happens... we can
have a default error report for cases when the embedding app doesn't handle the
error itself, if we want.
Doesn't the error pages system give embedors what they want? Doesn't that allow
them to hook up whatever URL result they want? Or are we talking about something
even more powerful, like an API?
QA Contact: adamlock → benc
No, the error page system absolutely does not give embeddors what they want.  In
particular, an embeddor who wants to use alerts instead of error pages can't.
bz: right now, you get a choice via:

browser.xul.error.pages.enabled

You can use alerts -or- the error page stuff. So what I'm asking is: do we need
yet another more generalized API?
Summary: JavaScript can not override the File-Not-Found alert issued by browser → JavaScript can not override the File-Not-Found alert
Well, that's a separate question.  This bug is about introducing such an API, so
embeddors get full control over what happens with errors as opposed to the list
of two choices that we have now.  I really have no opinion on the issue,
myself....  someone who has embedding experience should weigh in.
Assignee: adamlock → nobody
QA Contact: benc → docshell
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.