Closed Bug 28586 (errorpages) Opened 25 years ago Closed 3 years ago

[meta] meta bug - show error pages instead of dialogs for network errors (placeholder page in the content area) (http error pages)

Categories

(Core :: Networking, enhancement, P3)

Product:
Core
Component:
Networking
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: mpt, Unassigned)

References

(Depends on 3 open bugs, Blocks 4 open bugs)

Details

(4 keywords, Whiteboard: [Hixie-P0][Hixie-1.0][wgate][MB])

Attachments

(3 files, 10 obsolete files)

Does Netscape marketing _not_ see an opportunity here? Wouldn't you rather be redirected to a helpful netscape.com/mozilla.org instead of being forced to click OK?
5.56 KB, image/gif
Details
A page that IE generates for not finding a site.
2.22 KB, text/html
Details
Updated patch
43.04 KB, patch
adamlock
: review+
adamlock
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
To reproduce, either:
* Run Mozilla on a system which uses a dialup connection, but do not connect the
  dialup connection.

Or:
* Run Mozilla on a network which requires you to connect to a proxy server, but
  specify `Direct connection to the Internet' in proxy prefs.

Then:
* Try to go to an URL, or open a sidebar which requires Internet access.

What happens:
* A dialog opens saying something like `Mozilla's connection was refused by the
  server foo.bar.'

What should really happen (in my opinion):
* The frame, or sidebar, should open an error page (probably written in XML/CSS,
  for i18n purposes) which explains that the page is not available.

To see why an error page should be used, instead of a dialog, imagine the 
following scenarios:
* A Web server sends me an HTML frameset which refers to half a dozen frames, but
  somebody trips over a cord and disconnects the server before it can send any of
  the frames. Result: I have to click `Ok' on half a dozen dialogs. Yuk.
* I have half a dozen browser windows open, loading various pages, when my
  dialup connection disconnects. Result: I have to click `Ok' on half a dozen
  dialogs. Yuk.

The error page solution also has the usability advantage that it can be used as a 
`place-holder' for the real page -- so, for example, after browsing elsewhere for 
a while I can use the Back menu to come back to the error page, and then click 
Reload to have another go at connecting, without having to type the address (or 
find a link to click on) again. I can't do that with a dialog.

Problem occurs on: Mozilla nightly build 2000021608, MacOS 8.6
Does not occur on: Internet Explorer 4.0 or higher
Good idea.  This should probably go to Networking, CC: UI.
Assignee: cbegle → valeski
Component: Browser-General → Networking
I agree. I also noticed tonight that sub-documents that can't load also get this 
dialog, and that seems bogus since layout is responsible for putting up some alt 
text or image if the load fails.
Target Milestone: M16
Moving to M17 (also beta2).
Target Milestone: M16 → M17
Keywords: beta2
Whiteboard: 2w
Keywords: nsbeta2
tever, do you see this with latest commercial build?  Can you give us feedback 
on what is currently seen?  Is foo.bar in dialog still there?  Can you not get 
to sub-directories?
QA Contact: asadotzler → tever
Whiteboard: 2w → [NEED INFO]2w
Spoke with valeski - Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [NEED INFO]2w → [nsbeta2-]2w
*** Bug 43266 has been marked as a duplicate of this bug. ***
PLEASE add a preference setting to choose between error pages or dialogs if
you're going to impliment this. I HATE the damn error pages in Internet
Explorer. If something fails, I really prefer having the previous page still 
in front of me instead of a blank error page because then I can try something
different from that previous page instead of having to hit back and try it
again.

Furthermore, Please put the error codes on the TOP of that error page instead
of the BOTTOM of the page like Internet Explorer. You wouldn't believe how
many times I have the following conversations with Internet Explorer users:
"HEY! That page doesn't work!" 
"What error code do you get?" 
"I get a page saying "This page could not be displayed"".
"Yes, but what does it say on the BOTTOM of that page?"
"What page? It wouldn't load!" 
"You know the page that you got instead? What does it say at the bottom of it?"
"It says "The page could not be displayed!" 
"No, what does it say at the VERY BOTTOM of the page?" 
"Something about how I have to hit Refresh, which I already DID!"

(Eventually, I get them to hit page down and they FINALLY tell me the error
message at the very bottom of the page). Lots of times, it's a damn 404!

jce: relax. I'll write the text myself, if necessary, so that the name and number 
of the error is prominent at the top. IE's error pages are often downright wrong 
in what they say (due to being over-general), but Mozilla's won't be.

An error page should apply not only to unreachable servers, but also to
* form submission results which are no longer in the cache
* HTTP errors (in which case we'd have a brief explanatory header at the top,
  with a link to the relevant help topic, followed by the server's own error
  message).
Valeski, if either of these need separate bugs, tell me and I'll go file them.

I think this one comes down to personal preferences, which is why I would
really appreciate if we could choose between getting error dialogs or error
pages. Please tell me if I could help with this.

I would provide arguments why using dialogs are better then error pages, but
this seems to be a personal preference thing, so that wouldn't really be
constructive.
Umm..I meant that the USER should be able to choose between getting error
dialogs or error pages by selecting something in the preferences menu.
(I thought I should clarify that. :-) )
Summary: Should use error page, not dialog, for inaccessible pages → Should use error page, not dialog, for inaccessible pages (placeholder)
Blocks: 8345
Summary: Should use error page, not dialog, for inaccessible pages (placeholder) → [RFE] Should use error page, not dialog, for inaccessible pages (placeholder)
Target Milestone: M17 → Future
Keywords: nsbeta1
See also bug 45131.  Some people think this is a bug (as opposed to room for an 
rfe) when it occurs on a frame or iframe, because it interferes with 
ad-blocking.
*** Bug 68325 has been marked as a duplicate of this bug. ***
I think a modal message box for error on accessing page is a bad idea!
What useful purpose it can possibly serve that won't be serve by error
page or icon?

Probably the best method is if the browser give different error formats
depend on the context. If it is a main page or a frame, then a error page
will be produced. If it is an embedded object ("<IMG SRC..." etc.), then
an icon should appear.

I don't the structure of mozilla, but a good design will let the code that
produce error message about the same level as the code that display the
page, therefore the code that produce the error message will know the
context of the error and can act accordingly. The lower lever (deal with
network, etc.) should not ever produce any display, instead just pass the
error code to higher level.

Thanks!

a reason to use a dialog is for when you accidentally get redirected from a 
page that will not cache.  Suppose you have a page that behaves like netscape 4 
when viewing google cached pages that include css except that the css page 
can't be found.  The result is that you are redirected to an error page and 
can't go back to the page you want.  if instead you get an error dialog, you 
can move it out of the way and still read the page.

I'd prefer an error sidebar.  [Of course sidebars have to be able to float as 
if they are documents]

killing 2w since this thing was futured
Keywords: nsbeta2
Whiteboard: [nsbeta2-]2w
That's a problem for any page which does redirects, not just pages which redirect 
to error-causing URLs. There's no particular reason that it should be easier to 
stay on a page which redirects to an error-causing URL than it is to stay on a 
page which redirects to a valid URL.

I agree with Matthew.
I'd really like to encourage the switch to error icons for inaccessible embedded
content by 0.9. I for one recently started blocking certain sites in my hosts
file and have had to give up Mozilla for daily browsing for the time being for
another Mac browser that does display error icons for such inaccessible content.
*** Bug 70846 has been marked as a duplicate of this bug. ***
*** Bug 78896 has been marked as a duplicate of this bug. ***
qa to me.
QA Contact: tever → benc
I'm in the same boat as Greg.  The status of this bug will be the primary
determining factor in whether or not Mozilla will become my primary browsing
software.

I strongly encourage the Mozilla team to eliminate those error windows and add
icons to signify unreachable hosts.
Another big advantage of error page is that it would always be possible to ask
Mozilla to retry the problematic URL just by pressing "Reload". With dialog,
there does not seem to be a way to retry the communication. OTOH with error page
you can even continue browsing and later go back to the error page using the
"Back" button and press Reload.

Yet another advatnage is that the error page can be save and/or e-mailed (for
example to report the error to the server admin), while dialog can not.

Alos, with frames, the error page gives you a better visual hint of what part of
the page is unavailable.

P.S. I am using a local proxy server (squid), so in most of the cases I will get
the error page (from proxy) and not a dialog. I can attest that error pages are
infinetely more convenient and easy to deal with. Additionally, if Mozilla will
use error pages, it would mean that its behaviour would be more consistent, no
matter whether proxy is used or not.
Keywords: mozilla0.9.2
And for god sakes, have a network admin design the page.

If I get *one* more report from a user saying the network/Internet is down, when
it's just some dumb websites broken DNS...

Boy I'd love to meet the guy who designed IE's error page...

Added a vote, we're in double digits now...
Same as a lot of folks here. This bug is the one that prevent my company to use 
mozilla. It will solve problems (Bug 33469) of a lot of people, please vote.
After some experimenting, I realized that Mozilla is already handling inaccessible 
embedded images well, in that either the ALT text or, in its' absence nothing at all, is 
being displayed. No error dialog is shown, which is good.

It appears that IFRAME elements are the culprit. When these specify a URI that is 
inaccessible, an error dialog is shown. Presumably the same problem would apply to 
EMBED or OBJECT elements (though OBJECT embedding of text/plain or text/html is 
still broken; see bug #678).
Even if it's just a link that I've clicked on, I still want to see the error
page, not a dialog.
My guess is that if this bug is fixed properly, the bug #74987 "Specifying an
invalid URL using OpenURL via x-remote should display error message" is likely
to go away - if the networking code always produces an error page as its output
when some error occurs, it will also produce an error page for the URLs
communicated through x-remote.
Blocks: 74987
As the reporter of this RFE, a small note to those on the CC/supporters list:
If you want this bug to be fixed, then fix it, or find someone who can. Voting 
for it won't get it fixed. Spamming the bug report with useless comments about 
how useful it would be to your particular company/ISP/tiddlywinks club/whatever 
won't get it fixed. The only thing that will get it fixed is code. Thankyou.
I agree about the spamming comment (see bug 53080 for some of the worst of 
open-source bug tracking), but I want to encourage people to vote, because it 
does matter (and it takes little time).
*** Bug 82947 has been marked as a duplicate of this bug. ***
Bug 77635 deals with an error message appearing in a Sidebar tab rather than a
dialogue if the tab can't be loaded. The significant thing is that it's in the
process of being fixed. Perhaps some of the code could be reused to fix this bug
(though apparently the current fix is a bit hacky).
Whiteboard: [Hixie-P1] (not a standards compliance bug per se, but...)
Ok, so instead of complaining about this bug, let's design a solution to this. 
Here's one:

Let's implement an error service which allows us to control what happens with
errors, including displaying a page.  This would also be VERY helpful to
embedders, because it would give them a single point to handle (or override)
error displays.

What should an nsIErrorService look like?  What methods do we need?  Where does
it need to be hooked in?  If we have a design, it CAN get implemented.

*** Bug 86658 has been marked as a duplicate of this bug. ***
*** Bug 88708 has been marked as a duplicate of this bug. ***
Blocks: 88810
*** Bug 89252 has been marked as a duplicate of this bug. ***
Marking mostfreq at 10 bugs.
Keywords: mostfreq
Sorry for spam, but i wanted to give you an example problem i have lived with
IE5, there was a page with some banner ads on it and while i wanted to enter
that page,  there was no connection with those ad servers. And after loading
quite, at the end a page appeared telling inaccessible page because of those
banner ads. You must consider such problems i believe.
Blocks: 91632
bug 91632 was filed as a dependant on this one in order to fix the "connection
refused" window taking focus in mail, where we cant use an error page
No longer blocks: 91632
Blocks: 91632
Whiteboard: [Hixie-P1] (not a standards compliance bug per se, but...) → [Hixie-P0]
Blocks: 61685
I would say that Mozilla's error pages should be used only where we use a dialog
now - e.g. can't lookup server, etc. In addition, it would be *nice* if HTTP
login dialogs were HTML pages as well, but that's completely optional.

I would strongly discourage using Mozilla error pages for HTTP errors. Many
times site administrators put up good 404 pages with a search link, etc. to help
users find the content they were looking for. In IE, they get a damn "your
internet is broken" page. Please don't do this. Most HTTP servers attach nice
HTML documents to their HTTP errors for a reason, and we shouldn't be overriding
this.
I believe IE only replaces a HTTP error page with its own if the page is less
than 512 bytes in size (I'm not certain about that figure). It assumes that
anything less than 512 bytes can't possibly be useful, but if it's over 512
bytes then the administrator has probably replaced the default error page with a
far more helpful one.
[QA ignore]

> I believe IE only replaces a HTTP error page with its own if the page is less
than 512 bytes in size (I'm not certain about that figure).

Which leads to people adding "magic" comments to the page so it goes "just
above" the limit. I believe it's a braindead way to do it. Mozilla should not
follow IE's lead here; it should unconditionally show the server's error page,
even if it's utterly unhelpful.
<QA Ignore>

>> I believe IE only replaces a HTTP error page with its own if the page is less
>> than 512 bytes in size (I'm not certain about that figure).

> Which leads to people adding "magic" comments to the page so it goes "just
> above" the limit. I believe it's a braindead way to do it. Mozilla should not
> follow IE's lead here; it should unconditionally show the server's error page,
> even if it's utterly unhelpful.

Sorry, I should have made myself more clear. I was only explaining how IE's
error page replacement system works, not endorsing it (personally, I'm ambivalent).

</QA Ignore>

I believe, this bug has the wrong owner, since valeski isn't in the networking
group anymore. REASSIGN to default. (Maybe that helps getting attention.)
Assignee: valeski → neeti
Resuggesting via keyword from an already-gone milestone to a realistic future one.
Keywords: mozilla0.9.2 → mozilla0.9.5
I'm working on an implementation for this.  It requires a few modifications to 
Docshell and Session History.  I'm assuming that if you go Back or Forward to a 
page that had a URL error, it should never try to automatically refetch from 
the server.  Only pressing Reload on the error page would try to refetch from 
the server.

Do we want generic error pages ("Server not found"), or pages that contain 
dynamic information ("Server foo.com not found")?  I'd have to do some more 
work if we need dynamic pages.  Can someone (Matthew?) come up with some nice 
HTML (or XML, or XUL) error pages/icons?  We need error pages for: DNS Error, 
Connection Refused, Socket Timeout, Protocol Handler not Found, and Port Access 
Not Allowed.  Also, "page not available in offline mode" (Bug 45421), 
and "resubmit post data for page no longer in cache" might be possible but I'd 
have to look into that.

As for HTTP errors like 404, my implementation won't cover that.  Since sites 
can provide their own HTTP error pages, I don't think this should cover that.  
A statusbar/panel for these errors could be done pretty easily on the XUL front 
end though.
IMHO we defenetly want "Server foo.com not found"-kind of messages. Preferabley 
in full html-color'n'glory :)

Yes please make history work the way you described, ie don't retry 
automagically on "back".

It would be really cool if we had some sort of error-reporting-interface that 
can be used to report all kinds of errors. For example by specifying a chrome-
url for the errorpage and then some extra messages that messages that should be 
inserted into that page.

For example the XML-parser could give the chrome-url to a page describing that 
a unrecognized entity is found in a XML-document and then send along
line-number and column-number in the loaded file where the unrecognized entity 
was found. It might even want to send along a copy of that line. So the 
errorpage-xml could look something like:

<error>
  <p>Unable to load XML page, an unrecongized entity was found at line
  <message id="line-nr"/> column <message id="col-nr"/>:</p>
  <p><code><message id="error-line"/></code></p>
</error>

(Ok, that message wasn't very user-frienly, but you get the idea)

And then the parser says that message-id "line-nr" should have value "114", 
message-id "col-nr" should have value "5" etc.


Don't wanna scare you off with something too complicated, just cranking out 
ideas ;)

The advantage of using chrome-urls is that that makes it possible for plugins 
to deliver thier own errorpages.

I think perhaps the simplest thing to do for now is to examine the errors that
generate these dialogs and decide which should remain dialogs (there are some),
and which should display in the content area.

Looking at
[http://lxr.mozilla.org/seamonkey/source/docshell/base/appstrings.properties#20],
I see six strings that appear to be those shown in connection error dialogs.
These can be classified into twosorts; 1) the first four, which are shown when
the connection request could not be completed for some reason, and 2) the last
two, which are alerts about reposting form data.

I propose that the first four of these simply be retargeted at the content area
 rather than spawning a new dialog. The form data repost errors should remain
dialogs, since they're prompting the user to take an action prior to accessing a
page.

It won't be necessary to show any buttons in the content area, obviously. The
text is the only thing that need show, although it should probably be larger
than it is presently in the dialogs.

For embedded documents that generate such errors (IFRAMEs and OBJECTs) no error
at all should be displayed when alternate content is available. However, if no
alternate content is specified, can Mozilla still draw the error in XUL in the
space intended for the IFRAME/OBJECT?
It's worth noting that fixing bug 96976 will alleviate one of the most annoying
problems of this bug; of IFRAMEs specifying blocked or otherwise unreachable
hosts. Most sites with advertisement IFRAMEs have a linked image inside the
IFRAME element, so if the IFRAME degraded properly and displayed its' alternate
content then there wouldn't be unnecessary dialogs to dismiss.
No longer blocks: 91632
*** Bug 92524 has been marked as a duplicate of this bug. ***
I routinely use the windows\hosts file to disable banner ads, perhaps not very
clever, but it works. e.g.

127.0.0.1
ad.doubleclick.net

Under IE this just results in empty boxes with an X and it speeds up browsing
and reduces irritating GIFs, but with Mozilla I have to press OK on every error!!

I think the empty image placeholder with a simple "missing" message is a good
compromise - letting most users know something is missing but in my case knowing
why so I can ignore it.


Neil Munro and others: Workaround:
Install a http proxy locally (and possibly let it do the blocking, which
probably works better than the hosts entries, because you can use regexps) and
let Mozilla use that. The proxy then delivers a such an error page to Mozilla,
which displays it in the iframe. All works fine for me (with Squid).
Of course that might be a lot of work on your side and have other disadvantages,
just wanted to note it. I agree that this bug should be fixed.
Another workaround is to route the annoying servers to 127.0.0.1, and to set up 
a local web server to prevent the "cannot connect" dialogs.  If the annoying 
sites you're blocking are pop-up advertisements, you can even set up your 
server to send this in its 404 response:

<script>if (window==top) { window.close(); }</script>
*** Bug 98831 has been marked as a duplicate of this bug. ***
Tim Hill - are you still working on this? Here's my suggested implementation

On an error, Mozilla generates an XML fragment like so:

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="chrome://global/skin/error.xsl"?>
<!-- type indicates general area of error -->
<error type="Network|Offline|XMLParse|Internal">
  <offline reason="Unavailable"/>
  <network type="HTTP" code="404">
    <!-- if site provided it's own page, that goes here -->
  </network>
  <network type="DNS" problem="lookup:failed"/>
  <xmlParse type="entity-not-found">
     <uri>http://microsoft.com/home.xml</uri>
     <line>64</line>
     <column>12</column>
  </xmlParse>
</error>

or whatever, obviously there'd only be one child node in the error XML. That XML
is then transformed by Transformiix into lovely XHTML which describes the error,
alows you to retry etc.

comments?
thanks -mike
> That XML is then transformed by Transformiix

Transformixx is optional, you can't use it for such a central function.
See also bug 20838, [RFE] Unreachable server should cause cached data to be 
displayed.  The placeholder page could include something like "You visited this 
page 2 days ago, and a saved copy is available in Mozilla's cache.  
<button>View _c_ached copy</button>" when an unreachable page is cached.
Well I suppose we could just use DOM transforms then, but XSLT would be better.
Why is Transformiix optional? Do you mean in different distributions? As it is
so useful I can't see why people wouldn't want it, but ok then, if XSLT is out,
then DOM code will have to do. More work though :( Apart from that, is this
workable?
> Why is Transformiix optional?

It lives in extensions and the rule is that nothing of the browser must depend
on anything in extensions, because the one compiling has the option to switch
any of that off (and the app should still work, of course). Let's say Mandrake
decides not to turn Transformiix on, it shouldn't be surprised by bug reports of
disfunctional error msgs.
Whiteboard: [Hixie-P0] → [Hixie-P0][Hixie-1.0]
Time to move it to components/ then...
*** Bug 91469 has been marked as a duplicate of this bug. ***
*** Bug 103962 has been marked as a duplicate of this bug. ***
Please also read my comments in bug 103962 (marked cuplicate of this one)

I'd like it if there would be a "Javascript console" like thingy for this error.
It could be made to automatically popup, or to show an icon in the statusbar if
anything goes wrong when trying to load anything from anywhere.

The same goes for mail/news they have the same kind error messages and you have
to click them away before you can read mail. I love to be notified of errors,
but they shouldn't be so prominent and oblitory to look at.
Blocks: 104166
Ok, here we go, I got it.. Somebody could hack this over the weekend.. 

Take the history Sidebar, rename it something like inaccessable DNS site.. 

(history already updates and keeps track of dns entries for sites you visit)

Hack the code so that you can change a pref to make the dialog box info update
into the sidebar instead

new sidebar should show site, erronous DNS errors that are normal dialog
popups.. like cannot connect to site X, with seperator for other types of error
blocks 

1) Mail/News errors.. 
2) DNS site errors 
3) Cannot find server X
4) other.  

I also agree we could hack the JS Console to do the same thing as it also keeps
track and dumps to the console when there is an error.. 

shouldn't be that tough to get this built.

and you can take care of the error by just clicking on like how the messages
keep track of read/unread by click or by keyboard navigation over the error.

..  walla... we have a error page and no more dialogs.. and I can click on them
anytime (tooltips needed as well)..

which all leads to a better end-user experience!!

-dman84 
Ick. I never use the Sidebar, and I find anything which automatically pops it up
to be an extreme pain in the ass. Don't bring the Sidebar into this.
Well, then hack the JS console and the dialog event/alert/warning handler to
send the messages to the new Website Error Console.. that is what most people
want right?


cuz84d: you're looking for bug 80293, a console for networking errors.  This 
bug is for placeholder pages.
ok, its close.. but I'll head over to it.  
I presume currently we are talking about error message on *any* inaccessible
object, not only inaccessible frame / page, correct? Should be, since my bug
#68325 on any inaccessible object was marked as duplicate of this one.

Are we going to have error console, then?

Personally, the most important thing is that the error message box is modal.
Just make it non modal will help a lot. Error console will be great. Having the
error console on the sidebar will be nice, but should not be necessity (some
people turn off their sidebar - I do).

Will this make it to 1.0?

Thanks.
As I understand it, the current plan is to replace the error alert you currently
get when trying to access an inaccessible page/frame with an error page. This
would occur in place of the content. This behaviour would be the same as IE
(except without the redirection to MSN).

For example, say you go to the non-existent site www.nonexistentdomain.com.
Currently Mozilla displays a modal error message. The plan is to put an error
page in the content area instead. Another example would be going to a page with
an <iframe> containing an ad from
www.thisadservergoesdownmoreoftenthanafrenchcrackwhore.com. If the ad server is
down then Mozilla will display the error page in the <iframe> rather than
popping up a modal dialogue as it currently does.

At this time there is no intention to replace server-generated error pages (404s
etc.), just errors that occur when a page/frame is inaccessible (server down,
non-existent domain name, connection refused etc.).

I'm not sure where all this console stuff came from.
Console suggestions should go to bug 80293.
Alex,

The console stuff came from: 
A: didn't realize there was a Console Bug 80239
B: suggestion to use a JS like console for all dialog error replacement
C: use a hacked sidebar for the same thing
D: it was a suggestion to tackle this one instead of an error page..       
(consolodate all dialog popup messages that affect user to more friendly)
E: Trying to get people to decide on something.. 
F: I cant think of F
G: hope to just see what kinda feedback it gets in terms of prefered fixage.

-dennis
Whiteboard: [Hixie-P0][Hixie-1.0] → [Hixie-P0][Hixie-1.0] [Aufbau-P2]
*** Bug 107252 has been marked as a duplicate of this bug. ***
Whiteboard: [Hixie-P0][Hixie-1.0] [Aufbau-P2] → [Hixie-P0][Hixie-1.0]
Attached patch Patch for docshell and webshell (obsolete) — — Splinter Review 

    
    

    
  

      
      
      
      

        Attached file
          
        Error page (obsolete)
        — 
      

    


  

    
    

    
  

      
      
      
      

        Attached file
          
        Error page javascript (obsolete)
        — 
      

    


  

    
    

    
  
Place netError.xul and netError.js in your
dist/bin/chrome/toolkit/content/global directory or jar-file.

I added a method to nsDocShell.cpp, LoadXULErrorPage(errorType, url)
which is called in the appropriate places if the pref
"browser.xul.error.pages.enabled" is true.

The following cases are handled:
(nsDocShell.cpp)
Protocol not found, Denied Port Access

(nsWebShell.cpp)
File Not Found, DNS Not Found, Connection Failure, Net Timeout


    
    

    
  
Adding keywords to get people's attention, removing target since it's gone already.

Anybody care to nominate this for a 0.9er?

mpt, want to work with Martin to get this done? Seems like he's got some headway
into it already
Keywords: mozilla0.9.5 → patch, 
          
            ui

    
    

    
  
Shouldn't this page use the search engine that the user has selected in the 
preferences?  Also, "Google this URL" isn't exactly a professional looking 
button.

    
    

    
  
Very true, neither are the error-messages. If people like it, it is a simple
matter of adding localization files and some icons to have a usable solution.

This solution is however very crude compared to what Tim Hill wrote in his
comment, however he doesn't seem to be work on this given his absence from bugzilla.

(Adding me to CC-list).

    
    

    
  
Nobody wants the modal windows but i think nobody wants to be forced to go to a
mozilla/netscape site and waste our time and bandwidth seeing stuff we dont
want. We want to see a very simple LOCAL page displaying the error message.

    
    

    
  
No, I'd rather not be redirected to a page on netscape.com or mozilla.org.  
Most of the time I get a placeholder page, it's either because 
- my uplink is having trouble, or
- I misspelled part of the URL and am already in the process of correcting it.

    
    

    
  
You'd have to talk to marketing, which is not strongly present here. From
mozilla's standpoint, I think many contributors are concerned about creating
features that hard-code privacy disclosures.

We already have that problem with internet keywords, which sends people to a
search engine on the network when they they type a single word in "Location".
The page that is generated on search.netscape.com means that Netscape gets to
log every one of these queries.

    
    

    
  
==== From Alex Bishop 2001-10-23 08:34:
the current plan is to replace the error alert you currently get when trying to
access an inaccessible page/frame with an error page.
====

Is is mean that this bug only deals with inaccessible *page*? 
Is it mean that this bug doesn't deal with inaccessible objects (images and
other embedded objects)?

Should bug #68325 (about modal error page on inaccessible images) be reopened?
If this bug (28586) doesn't deal with inaccessible objects, apparently
reassigning bug #68325 as duplicate of this bug is an error.

Thanks.

    
    

    
  
Arif, inaccessible images don't produce an error dialog at all, at least not
using Mac/2001101117. If you are able to reproduce such a problem, please reopen
the bug you refer to and provide detailed information.

    
    

    
  
Don't images produce an error message if they come from a third-party server?

    
    

    
  
No. Please review my comments of 2001-05-15 15:59 on this bug.

    
    

    
  
I'm really interested in fixing this. However I'd like to know if this way of
solving it is sufficient or how I should enhance it. The idea of an
nsIErrorService appeals to me but that would broaden the scope drastically. 
 
What data do we need to pass to the xul dialogs? Is there a better way of
passing data (errorType, URI, ...) to a XUL document when loading it via LoadURI
 similar to window.open?




    
    

    
  
*** Bug 100135 has been marked as a duplicate of this bug. ***

    
    

    
  
Martin, dont know who knows that info, maybe Blake, he knows the XUL and stuff.. 

    
    

    
  
*** Bug 111739 has been marked as a duplicate of this bug. ***

    
    

    
  
Can this bug be targetted to something other than New?  With the increasing use
of ad blockers, firewalls, etc., this is quite a turn-off.  

    
    

    
  
try this in 2001-11-25.. w2K I see the message for a HTTP 404-Not Found Item..

-------
The system cannot find the file specified. - The Tab's Title is: Error 
-------

At least some dialog is gone.. woohoo!!!! 



    
    

    
  
scratch that: Must be a fluke:  Darn: URL I tried: no icon showed on URL bar
either when I first tried.

 http://www.devgames.com/GlideUnderground/



    
    

    
  
*** Bug 113093 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 114722 has been marked as a duplicate of this bug. ***

    
    

    
  
This is causing huge problems for us with K-Meleon. Since K-Meleon has pop-up
and domain blocking settings in our Preferences, we have a lot of people who use
the feature to block ads, etc. But they are getting overwhelmed with dialog
boxes from the blocked sites.  It's really an issue that needs to be addressed
quickly.

    
    

    
  
I don't think this is a good idea.

What if a frame whose server could not be found (for which now a dialog pops up)
is rather narrow, so that the error page could not be completely displayed?

    
    

    
  
This would be a bad design from the site. Anyway, you can always make the frame
full page if you want to see the error message.

    
    

    
  
*** Bug 117279 has been marked as a duplicate of this bug. ***

    
  
Keywords: helpwanted
Whiteboard: [Hixie-P0][Hixie-1.0] → [Hixie-P0][Hixie-1.0][wgate]

    
    

    
  
"The connection was refused when attempting to connect to ads.web.aol.com."

A 9920 line file on my system "hosts"- see  <http://www.smartin-designs.com/>)
contains in part:
127.0.0.1 ads.web.aol.com

These popups (on eBay search results) I have no need to see over and over and 
over and over and over and over, much less ever at all. I have to click 
OK three times on each page. Make them go away. This wasn't happening with
release 0.9.7.

Votes now showing: 49. Mine makes 50.


    
  
Keywords: mozilla1.0

    
    

    
  
Chris, regarding comment #98 that is really about bug 80293, get those over to a
new tab, or console, while this bug is really about not find websites in general.

    
    

    
  
*** Bug 124086 has been marked as a duplicate of this bug. ***

    
    

    
  
Gee.

Can we all stop talking about it and just fix the damn thing?

This is a real pain and ANYTHING would be better than that stupid dialog box

Even no warning at all would be better (configuarable by a pref of course).

This should DEFINITELY by fixed by 1.0


    
  
Blocks: advocacybugs

    
    

    
  
*** Bug 124145 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 124420 has been marked as a duplicate of this bug. ***

    
    

    
  
Gagan, darin, can you guys skim for content here and give advice on whether and
how to fix this bug?  Thanks.

/be

    
    

    
  
fwiw wgate currently has a very ugly hack which results in error pages instead 
of error dialogs. However thanks in part to mpt and other things I'm going to 
have to add extra ugly code to distinguish between javascript alerts and 
netwerk errors.

We really want an error service but would be happy if the default 
implementation just threw up an alert.

    
    

    
  
We have an outstanding Penzilla bug that would be satisifed by this RFE. I'm in
support of the mozilla1.0 nomination. Adding myself to the cc list.
Keywords: oeone

    
    

    
  
The patch is old and full of evil tabs.  Can someone refresh it and make it all
righteous and good?

/be

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch for docshell and webshell (obsolete)
        — 
          — Splinter Review
      

    


  
I updated the patch from attachment 55657 [details] [diff] [review] to apply cleanly to the current trunk
and to use "unified" diff format. I did it purely "syntactically" - I haven't
even checked whether it compiles.

        Attachment #55657 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached file
          
        Error page (obsolete)
        — 
      

    


  
Updated attachment 55659 [details] to be free of "evil tabs".

        Attachment #55659 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached file
          
        Error page javascript (obsolete)
        — 
      

    


  
Updated attachment 55660 [details] to get rid of "evil tabs".

        Attachment #55660 -
        Attachment is obsolete: true

    
    

    
  
use NS_LITERAL_STRING instead of NS_ConvertASCIIToUCS2 for literals, that's much
faster if supported

    
  
Blocks: 96887
Blocks: 84128

    
    

    
  
-> docshell
Assignee: neeti → adamlock
Component: Networking → Embedding: Docshell
QA Contact: benc → adamlock

    
    

    
  
just curious if there is a UI for this error page around here?  Do we wanna copy
MS's error page like in IE4.0?  dunno about newer versions of IE at the moment.

    
    

    
  
*** Bug 127264 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 112598 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 127598 has been marked as a duplicate of this bug. ***

    
    

    
  
Will this patch be compatible with embedding apps?

    
    

    
  
It should be compatible with embedding apps. Because it checks the
"browser.xul.error.pages.enabled" pref first, alerts though nsIPromptService are
still possible. An application could choose not to show the pref to the user and
just hardwire it to false if they wanted.

But, bailing on failing to get the pref isn't good.

+            rv = mPrefs->GetBoolPref("browser.xul.error.pages.enabled",
&errorPagesEnabled);
+            if (NS_FAILED(rv)) return rv;

That means that, assuming an embedding app is using its own default prefs, if it
doesn't contain this pref, this code will just fail without doing anything. Can
you instead treat failure to get the pref as FALSE?

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch for docshell and webshell (obsolete)
        — 
          — Splinter Review
      

    


  
Probably re-introducing a lot of evil tabs (Emacs is probably too smart for me
and I couldn't find any FAQ or coding style guide right now, so here we go).
 
Anyway, this applies cleanly to the trunk and actually works.

    
    

    
  
+    nsAutoString errorPageUrl;
+    errorPageUrl.AssignWithConversion("chrome://global/content/netError.xul?uri=");

Why don't you use
nsAutoString 
errorPageUrl(NS_LITERAL_STRING("chrome://global/content/netError.xul?uri=")); ?

At least use
errorPageUrl.Assign(NS_LITERAL_STRING("chrome://global/content/netError.xul?uri="));



    
    

    
  
This should be fixed as soon as possible, as some folks prefer to redirect
advertising hosts to localhost where there may not be a server running.

    
    

    
  
Patch exists. Nominating for nsbeta1. Adding embed keyword on basis of comment 97.
 
Actual behavior: Error alerts for inaccessible pages are modal dialogs.

Expected behavior: Error alerts for inaccessible pages are error pages.

Keywords: embed, 
          
            nsbeta1

    
    

    
  
*** Bug 97641 has been marked as a duplicate of this bug. ***

    
    

    
  
minusing nsbeta1 as I don't think the next NS beta release has this change in
the works. adding topembed nomination keyword as this is something some
embeddors indeed need. will consider topembed+ once patch has made it's round of
reviews.
Keywords: nsbeta1 → nsbeta1-, 
          
            topembed

    
    

    
  
*** Bug 129681 has been marked as a duplicate of this bug. ***

    
    

    
  


  
This is what you get if you hit IE's Stop button.. I'd say mozilla would look
good with something similar.

    
    

    
  
Please don't copy the Internet Explorer error pages!
They are designed very badly, because the important message
(i.e. error code and explaining message) is at the very bottom
of the page (if the window is too small, one has to scroll
down to see it) and it's in the smallest font.

If you want to write an essay, what 404 means and what one 
can do about it, that's fine. But copy the text after the 
important error summary ("404 file not found").

    
    

    
  
Raphael, DON'T SPAM the bug report.

The issue was already brought up in this bug. 

Use newsgroups for discussion. This bug is long enough.

    
  
Keywords: topembed → topembed-

    
    

    
  
*** Bug 131215 has been marked as a duplicate of this bug. ***

    
    

    
  
qa to me:

Do people think that fixing 111904 would be a good solution if we do not fix
this bug? If so, go in that bug and vote, or comment if you have something
constructive to add (no "me too!" comments).

spam isn't the problem, its the duplicate count.

I don't suppose anyone would like to look through all the dupe's activity
reports and find out where they are coming from? Probably networking.

I am thinking about creating a "trap" bug in Networking that has a subject that
will tell people, "yes we figured out this a problem, no you should not file
another duplicate..."


QA Contact: adamlock → benc

    
    

    
  
Benjamin Chuang: for me just fixing the 'site not found' dialog would be a
partial anoyance fixer, but not solve the main problem i currently have with
mozilla.

We are trying out mozilla on internet kiosks, web pads and top set boxes, and
most of these 'embeded' style devices usualy try to avoid anything 'window
manager' like. Dialog boxes are evil and reserved for fatal errors

Also dialog boxes for 'could not connect' or 'site not found', etc are
questionable in use. They give feedback, but do not 'dialog' (there is no
option, its just a information notice). The main window is a perfect place for
giving this information (for less important things one uses the status bar)

Only if an error is fatal 'Mozilla will self destruct now', should one be
tempted to use a dialog box ;-)

    
    

    
  
(I'm just trying to get as much done for 1.0. If it misses 1.0, then a lot of
people who want to build off of it will need to grab a pile of patches. Every
missed fix will be a pain that grows linearly.)

    
    

    
  
which is the core reason I still am seeing regressions that are not helping
moz1.0, and think we should give it a few more weeks.. 

there is already a patch here, has anyone tried it.. or does it need more work?

-dman84

    
    

    
  
Has patch, highly desired, useful for embedders. Adding mozilla1.0+ keyword to
see if we can find reviewers and testers.
Keywords: mozilla1.0 → mozilla1.0+

    
    

    
  
With regards comment 133, I've looked through all the dupe activity reports. Out
of the 31 dupes, 16 started life as Browser-General, 8 as Networking (3 of these
Networking:HTTP), 5 as User Interface Design, 1 as Preferences, and 1 as
Security:General.

Hope that helps. I can upload the gory details if required, although I
guess/hope this bug is going to close soon.

    
    

    
  
adding self to cc list
Whiteboard: [Hixie-P0][Hixie-1.0][wgate] → [Hixie-P0][Hixie-1.0][wgate][MB]

    
  
Whiteboard: [Hixie-P0][Hixie-1.0][wgate][MB] → [Hixie-P0][Hixie-1.0][wgate][MB][WTFATCA]

    
    

    
  
I tried testing this but I couldn't since I don't know where to put the new
files (I don't have a dist/ directory until after building, obviously...).

Could we have a single -uN diff that has the files in the right place?
Whiteboard: [Hixie-P0][Hixie-1.0][wgate][MB][WTFATCA] → [Hixie-P0][Hixie-1.0][wgate][MB]

    
    

    
  
*** Bug 136889 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 138411 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 55788 has been marked as a duplicate of this bug. ***

    
    

    
  
The webshell/docshell patch looks okay to me, but please resubmit a clean
version against the trunk for review. Also include any patches needed to the
chrome & makefiles required to report the error.

docshell/webshell are a mess of error reporting code, so there may be future
scope for splitting this out into a service but don't concern yourself with that
for now.

    
    

    
  
*** Bug 143523 has been marked as a duplicate of this bug. ***

    
    

    
  
I think the patch for docshell/webshell cannot work with the current trunk. It
needs some updates (which I'm not able to do by myself :-)).

    
  
Blocks: 111904

    
    

    
  
I use AdShield to block access to sites such as ad.uk.doubleclick.net who supply
advertising material. At present I receive an Alert dialogue from Mozilla
whenever Adshield blocks access; this can sometimes occur two or three times on
a single web page. You now seem to be discussing whether to continue to hit me
with the dialogue or with an error page. Well, I'd prefer neither, thank you
kindly, not when access has been blocked on my instruction. May I suggest a mere
message in the status bar when page elements fail to load in this way?

    
    

    
  
bertknight@hotmail.com, you have the same problem I have except I use the hosts
file to do that job. Getting rid of the modal dialog is bug 111904, which this
has been marked to depend on.

    
    

    
  
Bert, Mozilla has no way to know whether you decided to block the or if it's
unreachable because of another reason. Therefore it displays the dialog.

Use another way to get rid of banners, or wait until this bug is fixed, thank
you kindly.

    
    

    
  
For the time being, I recommend bannerblind for you. http://bannerblind.mozdev.org/ 

    
    

    
  
bannerblind doesn't solve the problem. URL: http://www.voyages-sncf.com/
So, this bug should really be fixed.

    
    

    
  
It does for me, just add the size of the banner to bannerblind and all is well.

    
    

    
  
[OT] The size is ticked and BannerBlind is enabled. So, it seems to be a bug in
BannerBlind. I'm going to report a bug on mozdev.org.

    
    

    
  
Not a BB bug. It doesn't block IFRAMEs, and that page contains one.

Let's keep the comment traffic down on this bug. It's too long as it is. Take it
to the newsgroups, please.

    
    

    
  
*** Bug 111904 has been marked as a duplicate of this bug. ***

    
    

    
  
Now that bug Bug 111904 has been duped to this, this needs to be changed from 
enhancement to major or worse. Modal dialogs should not be popping up on blocked 
inline elements.

    
    

    
  
IMO we're getting sidetracked quote a bit..

Please read the original comment. This bug is about the modal diagog that pops
up for _any_ error. This includes completes pages that can't be opened.

Besides that; who is working on this or will work on this? And what happened to
Tim (comment #45)?

There are a lot of perfectly good suggestions in this bug so a lot more
discussion is just a wast of time :D Could someone just write this patch? :D *grin*

Anyway, in the meantime it would help a _lot_ if someone could make the dialogs
non-modal. This modality lead me into thinking that mozilla became inresponsive
quite a few times. Pretty annoying.

So IMO this bug is about getting totally rid of the modal dialog, not just
removing it in case of failing inline elements.

Oh, about the banner removal stuff, IMHO it's just plain theft.. How are website
owners supposed to generate any revenue if everyone is just scrapping their ads?
Websites cost money you know :D

Anyway, back to the bug... I vote for upgrading this bug too. 'enhancement' just
doesn't do right to this. It's one of the most duplicated bugs and we have 81
votes already.

    
    

    
  
this bug _is_ an enhancement, even though it prevents some people from using a
completely inappropriate method for blocking ads.
mozilla behaves perfectly correct even without this bugfix.

    
    

    
  
Retargetting.

I'm looking at this at the moment.
Target Milestone: Future → mozilla1.1alpha

    
    

    
  
Bug 111904 had keywords mozilla1.0, nsbeta1, review, and should have had 4xp and
regression. Before late November when 111904 was filed, modals were not blocking
browser progress. 

Until Mozilla is ready for full prime time displacement of other browsers, users
have to do whatever works with the other browsers. People who want to use both
at once are forced to choose between fighting modals in Mozilla, or having to
navigate with nothing blocked in the others. Note
http://bugzilla.mozilla.org/show_bug.cgi?id=111904#c9 and
http://bugzilla.mozilla.org/show_bug.cgi?id=111904#c14
The attitude that current behavior in Mozilla is correct needs to be shelved
until these hurdles are overcome.

    
    

    
  
I don't think it is only an enhancement. When the domain of a banner can't be
reached (this can happen even when the user doesn't block ads), this may make
browsing almost impossible under some conditions. Mozilla should behave in a
sensible way.

    
    

    
  
This is not going to make it into 1.0 because the change is too substantial.

The current plan is to merge & update the patch against this bug with the one in
bug 111904.

    
  
No longer blocks: 111904

    
    

    
  
*** Bug 111904 has been marked as a duplicate of this bug. ***

    
    

    
  
I would like to add that this error is not only relivant for people who
blackhole certain (doubleclick) sites.

I use mozilla quite a bit on embeded en kiosk style devices, and the combined
strenght of tabs + mozilla's good support make it a real strong combination.

However dialog boxes are a evil, evil thing on kiosks or embeded devices. (It
confuses the **** out of a user if modal dialog boxes pop up, specialy since it
is the only dialog box they will ever run into on those devices)

To be able to completly hide the window manager from the user, it is a nescisaty
to display these errors in a page, and not using dialog boxes.

Since the faulty (misspelled or non existing URL's) user input is the top most
cause for 'errors' on these devices, this makes it a very hot topic for anyone
in that field.

Just my 2 Euro cents ;-)

    
    

    
  
Possible easy fix:
 Add checkbox to dialog box "Close All" - to close all error dialogs opend
during next 5 seconds
 Add checkbox "Show more errors for this site" - to solve problem with banner
server unreach.
--
Making HTML like error page is a bad solution. (I'm using squid - so know what
is  html error page is).
It must be something else. For example [x] - box with red cross or some image(s)
and pop-uped description about error on mouse over. (you can't read error
responce if HTML error page is inside 33x70 banner).
 It must be something, you can't spoof(emulate) with HTML page on site.

    
    

    
  
I think some HTML code should be generated and display should be controled with
CSS (and/or JavaScript).

As a user, I'm not interested in the error message, in particular when it is
about an advert.

    
    

    
  
In reference to comment 147 and all subsequent comments regarding popups for
inaccessible banner ads, an inaccessible banner ad should not show as an error
page but as a broken image placeholder (bug 41924).

    
    

    
  
Re: comment 167
Many ads are not just images, but iframes.  Therefore, bug 41924 is irrelevant.

    
    

    
  
*** Bug 147203 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 147329 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 147602 has been marked as a duplicate of this bug. ***

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Work in progress (obsolete)
        — 
          — Splinter Review
      

    


  
This patch is still work in progress. It works more or less but there are some
gnarly issues as to how the error page looks and how docshell passes stuff like
error codes and so forth to the page.

First a description of what has been done:

1. Docshell now has a variable mUseErrorPages, set from pref
"browser.xul.error.pages.enabled" to determines whether to display popup errors
or error pages.
2. If set to true, error pages are displayed and calls are made to the
LoadErrorPage function in nsDocShell.
3. Docshell loads netError.xhtml from chrome with the error code and URL as
arguments.
4. netError.xhtml splits out the error code and URL and displays a page
appropriate for the error. Error text is locale specific and contained in
netError.dtd.

Now the problems:

1. To keep netError.xhtml locale neutral, all the error strings and
descriptions are in netError.dtd which netError.xhtml pulls in as its dtd. This
means I can insert strings from netError.dtd into the page. In theory I should
also be able to insert entities dynamically (e.g. &dnsFailure.shortDesc;) into
a text node and they should expand it out. Unfortunately, entities are not
being expanded when I do this. Only static entities are expanded, not ones I
insert dynamically via js. Any ideas?
2. Webshell & docshell display error popups with formatted message strings. I
want to provide similar behaviour in the netError.xhtml so there may be need to
be further reworking to how strings are supplied and formatted.
3. nsDocShell::GetPromptAndStringBundle should probably be split into two
methods. There is no point grabbing the prompt service if it's not going to get
used.
4. appstrings.properties and netError.dtd should really be consolidated
somehow. appstrings.properties should be moved into the new
docshell/resources/locale/en-US dir I have created for this work. The
LoadErrorPage method has an arg to accept a short error description but current
ignores it.
5. The URL for the error page appears in the location bar. I should find a way
to suppress this, e.g. not set currentURI when loading the error URL.

        Attachment #69999 -
        Attachment is obsolete: true

        Attachment #70000 -
        Attachment is obsolete: true

        Attachment #70001 -
        Attachment is obsolete: true

        Attachment #71771 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        More work in progress (obsolete)
        — 
          — Splinter Review
      

    


  
Patch contains a new nsDocShell::DisplayLoadError that consolidates all the
error code into a single method. Now nsWebShell etc. call this one method
rather than displaying their own error messages. This makes things much, much
cleaner.

I've changed all %s in appstrings.properties to %S so the formatting for
various error strings is shared rather than being multiple implementations..

I've also changed the format for the formatting of error/url/descriptions in
the netError.xhtml URL to be more CGI-like. This enables me to pass the short
description of the error through to the page.

Problems still outstanding:

1. How to expand entities. I'm setting a text node's value to
"&dnsLookup.longDesc;" (for example) but the entity is not being expanded out.
I want it to expand to the value that it's meant to be as defined in the DTD.
How do I do this?
2. Suppress the current URI. The current URI should not be changed when I
display the error page. Mozilla should display the "bad" url in the location
bar.
3. Tweaks to the xhtml/js. I don't care what this page looks like from a
wording/stylistic point of view, but I need to ensure the mechanisms behind it
are sound enough that other people can improve it as they deem necessary.

        Attachment #85306 -
        Attachment is obsolete: true

    
    

    
  
The entity-support in our DOM is pretty weak so I would suggest that you put 
the strings in a .properties file instead of a .dtd file and use js to insert 
them.

    
  
Summary: [RFE] Should use error page, not dialog, for inaccessible pages (placeholder) → [RFE] Should use error page and not dialog for inaccessible pages  (placeholder)

    
    

    
  
I was wondering why this bug is marked as an enhancement and targeted for
1.1alpha. It is a _very_ annoying bug for people with dialup or independable
connections. I got my girlfriend to using Mozilla, and she likes it a lot (no
popups and virusses!), but she is ready to go back to IE because of it.

    
    

    
  
Re: comment #175

First of all, this is not a discussion forum, or IOW, it's not for whining.

> I was wondering why this bug is marked as an enhancement

Because inaccessible pages get an error message dialog. Now, people want it
enhanced, as a error *page*. Makes sense, huh?

> and targeted for 1.1alpha.

- Because it's too late for 1.0 (which is "literally finished" now, should be
either late this week or early next week)

- because, afaict, there is no full (as in, 0. doesn't need work 1. reviewed, 2.
super-reviewed and 3. approved) patch yet

- because 1.0.x will mostly fix bugs and not add functionality, as its common
with 3rd level version changes

> It is a _very_ annoying bug for people with dialup or independable connections.

Vote for it.

> I got my girlfriend to using Mozilla, and she likes it a lot (no popups and
> virusses!),

Yeah, but see, that won't help fix this bug.

> but she is ready to go back to IE because of it.

And that won't either. That's why we do not tend to appreciate "FIX THIS OR I'LL
RETURN TO <browser xyz>!", and not "THIS KEEPS ME FROM USING MOZILLA!" comments.

Just my 2 cents, and please don't spam this bug any more (there seem to be
roughly 100 cc's), kay? :-)

    
    

    
  
> > I was wondering why this bug is marked as an enhancement

> Because inaccessible pages get an error message dialog. Now, people want it
> enhanced, as a error *page*. Makes sense, huh?

Please refer to comment 160, and bug 111904, which was major and then duped to
this. This bug too should be major, as well as regression, since before last
November, modal dialogs were not being popped up due to unreachable embedded
elements. Bug 111904 should be unduped and fixed. There should not be an error
page displayed due to unreachable elements.


    
    

    
  
Putting up an error dialog instead of an error page is in no way "major loss of
function". Please make comments about how to resolve other bugs in their
respective bug reports.

    
    

    
  
> Putting up an error dialog instead of an error page is in
> no way "major loss of function".

It is if it's modal. I've had problems before with downloads being cancelled,
etc, because Mozilla has put up a "Can't connect to..." or "...cannot be
found..." dialog for some unrelated page while I've been away from the machine
waiting for it to finish. Usually happens when (has little to do with this bug,
sadly) the mail client can't poll my mail server, but also happens if I have a
auto-reloading frame in another tab, such as the Salon front page.

If I can't download something unattended without closing all other tabs, and if
I had mail and news open, exiting the browser completely and restarting, then
I'm experiencing "major loss of function." I reckon so, anyway.


    
    

    
  
Sorry for the extra chatter, but I just filed Bug 149037 as an intermediary
step, that might cut down some of the annoyance of this bug.

    
    

    
  
If a modal dialog is affecting other network activity, that would be a separate
defect, please file a separate bug.

    
    

    
  
modal alert dialog in any window blocks necko for all windows
http://bugzilla.mozilla.org/show_bug.cgi?id=74331


    
    

    
  
Re: comment 178:
I hope your comment didn't refer to my comment 177. When I start loading a page
in Mozilla and immediately leave Mozilla to work in another app while the page
loads, Mozilla should not steal focus from the other app to display: "The
connection was refused when attempting to contact ad.doubleclick.net." This
amounts to major loss of function. Mozilla should never steal focus from another
app." I don't know whether such theft is this bug, another bug like bug 111904,
or needs a bug, but needless focus theft *certainly* is major loss of function.

    
    

    
  
Wouter: To add a little to what Chucker said to you, which I viewed as maybe a
tad harsh. Each developer has a ton of bugs they are working on. This problem
might seem like the end of the world to you, but be assured - for the general
public, there are much bigger issues. We understand the fixing of this bug means
a lot to you, but there are also other bugs where people feel just as strongly
as you do about this bug.

You might want to consider the security issues of IE before your girlfriend goes
back to it:
http://slashdot.org/article.pl?sid=02/06/05/148244&mode=thread&tid=109

IE has terrible security issues, and Mozilla's security is tight. I consider
that a bigger problem than this issue since it could allow someone to get into
your hard drive.

    
    

    
  
mrmazda, yes, that is a bug, _but a seperate one_

    
    

    
  
If that is the case, then bug 126906 should not have been duped to bug 111904.
Bug 126906 reopened and probably depends on this.
Blocks: 126906

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch (obsolete)
        — 
          — Splinter Review
      

    


  
The first phase is ready for review I believe.

What it does:

1. Cleans up webshell and docshell error handling A LOT.
   All error reporting happens via nsDocShell::DisplayLoadError now.
2. Stops error messages appearing on IFRAMEs for the common errors
   (unknown host & connection refused).
3. Enables error pages if "browser.xul.error.pages.enabled" is set to true.
4. Has basic error pages.

I would like this to be reviewed and checked in before refining the behaviour
and to give the code a chance to soak. Phase 2 can be:

1. Putting a default pref and UI to control which behaviour to use.
2. Resolving a few issues in the error pages:
    a) Put some decent Plain English(tm) descriptions into the error pages
    b) Can the error URL be suppressed somehow
    c) What to do when user disables JS (error page is unprivileged XHTML)
    d) Hardcoded link to saerch google is a bit nasty

Reviews please?

        Attachment #85472 -
        Attachment is obsolete: true

    
    

    
  
Keyword changes: adding review; removing mozilla1.0+ since this obviously didn't
make it; adding mozilla1.1.
Keywords: mozilla1.0+ → mozilla1.1, 
          
            review

    
    

    
  
*** Bug 149978 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 150549 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 151075 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 152687 has been marked as a duplicate of this bug. ***

    
  
Blocks: 154414

    
    

    
  
*** Bug 155600 has been marked as a duplicate of this bug. ***

    
    

    
  
5 more dupes on this since Adam asked for review. Is this the most duped bug
ever? Anyways, who need to review/super-review this patch and get it in?

    
    

    
  
Comment on attachment 86662 [details] [diff] [review]
Patch

r= radha . I guess you could suppress urlbar update and back/forward button
update by checking for this error url in nsDocShell::SetCurrentURI() and
preventing a call to onLocationChange().  I'm not sure what happens to the
throbber in this case, sicne onLocationChange() handles the throbber,
back/forward buttons and the urlbar.

        Attachment #86662 -
        Flags: review+

    
    

    
  
Comment on attachment 86662 [details] [diff] [review]
Patch

r= radha . I guess you could suppress urlbar update and back/forward button
update by checking for this error url in nsDocShell::SetCurrentURI() and
preventing a call to onLocationChange().  I'm not sure what happens to the
throbber in this case, sicne onLocationChange() handles the throbber,
back/forward buttons and the urlbar.

    
    

    
  
Comment on attachment 86662 [details] [diff] [review]
Patch

sr=rpotts@netscape.com

This looks like a great start!	let's get it in and start shaving off the rough
edges :-)

        Attachment #86662 -
        Flags: superreview+

    
  
Keywords: approval

    
    

    
  
Looks great - cleans things up a lot. You need to add some code to
http://lxr.mozilla.org/mozilla/source/build/mac/build_scripts/MozillaBuildList.pm#529
 so that the contents of docshell/resources get built on the Mac.

    
    

    
  
I'll do a fresh patch against the trunk, including the mac/unix build changes,
verify it builds on all platforms and submit for approval.

As stated previously you'll need to set a pref to enable the error pages since
this patch is more about cleaning up error reporting docshell in preparation for
further work. Stage 2 will have to deal with the issues I listed (and others?)
before it can be enabled by default.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Updated patch
        — 
          — Splinter Review
      

    


  
Same as before with one makefile.win fix and the mac build changes at the end.
Still to verify on mac...

        Attachment #86662 -
        Attachment is obsolete: true

    
  

        Attachment #90804 -
        Flags: superreview+

        Attachment #90804 -
        Flags: review+

    
    

    
  
Comment on attachment 90804 [details] [diff] [review]
Updated patch

Carrying r/sr forward

    
    

    
  
Verifying patch works on win32, unix & mac.
Target Milestone: mozilla1.1alpha → mozilla1.1beta

    
    

    
  
Comment on attachment 90804 [details] [diff] [review]
Updated patch

a=asa (on behalf of drivers) for checkin to the 1.1 trunk.

        Attachment #90804 -
        Flags: approval+

    
    

    
  
The first patch is checked in. To try out error pages, edit your all.js prefs
file and add this line.

pref("browser.xul.error_pages.enabled", true);

You will immediately note that the error pages are basic. We still need someone
from usability or UI design to flesh these out and make them look nice and
informative. We also need to sort out some other issues which I mentioned
previously. The error page and code is in mozilla/docshell/resources. It is
unprivileged XHTML so it will run in iframes without security issues so please
bear that in mind.

This bug is painfully large already so please RAISE A NEW BUG that blocks this
one for each issue so it gets the proper focus. Once error page support is in a
decent state this bug will be marked fixed.

Status: NEW → ASSIGNED

    
  
Depends on: 156997

    
  
Depends on: 157004

    
    

    
  
Adam, can that pref alternatively be put in user.js?

    
    

    
  
You can either put the pref in your profile's prefs.js, or into
mozilla/default/prefs/all.js. If you prefer you can put it into user.js but you
may have to create that file.

    
    

    
  
I just filed a new bug introduced by this patch -
bug 157102: Back to error page crashes the browser.

    
  
Depends on: 157102

    
    

    
  
This is working with MFCEmbed July 12, 2002 nightly. Nice work Adam! I'm not 
seeing the crash on back button bug reported in:

http://bugzilla.mozilla.org/show_bug.cgi?id=157102

with MFCEmbed.

It does require two clicks of the back button to get back past the error 
message. Also, that message does not redisplay when going back through the 
history. I believe Adam is looking to keep the error message out of the browser 
history anyways, so I don't think that issue needs any extra attention.

    
    

    
  
Yea, nsIWebNavigation::LOAD_FLAGS_BYPASS_HISTORY won't bypass the page from
history when you use the back button.  I think it might just be a matter of
playing w/ the right load flags.

0.02c

--pete



    
    

    
  
fyi, I've put up the pref for enabling this on my website
<http://www.geocities.com/pratiksolanki/> to get broader testing. If you think
its better not to put it up, let me know and I'll remove it.

    
    

    
  
I tried the placeholder feature with 2002 071208.  Comments:

1. A chrome address appears in the url bar.  Instead, the bad URL should appear
in the title bar.  We could hide the chrome address the same way we hide
internal wyciwyg URLs in xpfe, but it might be nice to expose both the wyciwyg
fixup and this fixup to embedders.

2. Bookmarking bookmarks the error page.  I think the original address should be
bookmarked.  Another option is disabling bookmarking, but I prefer bookmarking
the original address because Ctrl+D is normally silent and would fail silently
if the menu item were disabled.  (This is also an issue with wyciwyg URLs!)

3. Hitting Reload should try again.

4. The Try Again link should not add an entry to session history.

5. "Search for this address" should be "Search Google for www.foo.com".  (The
location bar dropdown uses this text.)

6. The search link should use the search URL the browser would use.  Can you
call OpenSearch in navigator.js?

7. The search link should be a real link so that open link in new window and
visited-link coloring can work.

8. Clicking the search link and then the back button loads Java (!?) and gives
me a blank, gray page.  It should return me to the error page.

    
    

    
  
Is the idea to have the error pages in XHTML for now, and change them to XUL at
some point?

    
    

    
  
This is a meta bug. Please open new bugs or cc yourself to those that have
already  been opened to deal with issues like history/reload/url issues (bug
157004) and making it look nice (bug 156997).

Just to clarify the reason the page is XHTML (which is not set in stone BTW) is
because it has to be capable of loading in frames and iframes. I could have used
straight XUL but I thought it would look pretty stupid to have XUL in frames
inside content areas. The original patch had a XUL error page and it just looked
odd. I also believe there could be unforeseen security implications for running
XUL in this way so I didn't want to risk it. Even if it could run it would be
running with untrusted content privilege negating many of the reasons you might
care to use it. If someone can come up with a compelling reason it should be XUL
instead of XHTML, raise a bug and demonstrate it.

    
  
Depends on: 157527

    
  
Depends on: 157531

    
  
Depends on: 159071

    
  
Blocks: 159324

    
    

    
  
*** Bug 160423 has been marked as a duplicate of this bug. ***

    
  
Depends on: 160548

    
  
Depends on: 161276

    
  
Blocks: 160423

    
  
Blocks: majorbugs

    
    

    
  
*** Bug 165340 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 166343 has been marked as a duplicate of this bug. ***

    
    

    
  
Has this patch been committed to the trunk?  I'm using 1.2a and I still get the
modal dialog.

    
    

    
  
Anthony, you must add a hidden pref to enable it. See comment 210.

    
    

    
  
Selecting to top two lines in the error pages, and pasting them, procuce all the
error messages. This is very embarassing pasting it into an "enter-commits"
forum like IRC.

The operation timed out when attempting to contact www.bero.org.

  
  

    

malformedURI long description goes here.

  

  

    

fileNotFound long description goes here.

  

  

    

dnsNotFound long description goes here.

  

  

    

dnsNotFound long description goes here.

  

  

    

protocolNotFound long description goes here.

  

  

    

connectionFailure long description goes here.

  

  

    

netTimeout long description goes here.



    
    

    
  
that's bug 39098
Depends on: 39098

    
    

    
  
*** Bug 25618 has been marked as a duplicate of this bug. ***

    
  
Summary: [RFE] Should use error page and not dialog for inaccessible pages  (placeholder) → Should use error page and not dialog for inaccessible pages  (placeholder)

    
    

    
  
*** Bug 174911 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 175704 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 57867 has been marked as a duplicate of this bug. ***

    
    

    
  
Update target milestone to 'Future' since this missed the 'mozilla1.1beta' train.
Target Milestone: mozilla1.1beta → Future

    
    

    
  
Juan: Please, do not change the target field unless you are the bug owner.

Or unless he is dead... ;-)

    
    

    
  
Juan was doing me a favour by futuring some of my bugs. I don't have the time at
all the moment to look at any of the error page issues, so I welcome volunteers. 

    
    

    
  
topembed+ since this is one of those IE-ish things that some embeddors prefer. 
Keywords: nsbeta1-, 
          
            topembed- → nsbeta1, 
          
            topembed+

    
    

    
  
*** Bug 177353 has been marked as a duplicate of this bug. ***

    
  
Keywords: mozilla1.1 → mozilla1.2

    
    

    
  
This can't make it to mozilla1.2. It needs to be tested in the alpha release.

Keywords: mozilla1.2 → mozilla1.3

    
    

    
  
*** Bug 48850 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 184168 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 184489 has been marked as a duplicate of this bug. ***

    
    

    
  
Plase add posssibility just to disable ANY alert popups about time out and alike.
Why should I care if some of resources requested from current page are not
available?

I enter a page and in this page , let's say, there are hidden frames or any sort
of stuff like this for ADS triks or so. Some of resources can't be loaded and I
get 3-5 alerts "The operation timed out when ... etc. " about this wonderful events.

I need than to have possibility to disable any sort of such a messages.
If I'm ordinary user I do not care if this banner is not loaded.
In fact for ordinary user is quite enough to have message like 404 page.
If some JS files or CSS can't be loaded, than I as user can do nothing and I
really do not whant to know about this.

WBR

    
    

    
  
"This can't make it to mozilla1.2. It needs to be tested in the alpha release."

So is it enabled for 1.3a? I've had it enabled in my own profile for months now,
and while it's not perfect (history issue, hidden text issue), it's much better
than having alerts pop up all over. (What's the point of having popup blocking
features if the browser itself is going to popup things on you all the time?)

    
    

    
  
*** Bug 184841 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Comment 234 has been marked as a duplicate of this bug. ***

    
    

    
  
Add the posibility to do a google cache search if the page is not found, unless
the server returns a page saying that it was not found... Google cache is pretty
usefull, even when the site has been hacked.

    
    

    
  
I've also found the Internet Archive (http://www.archive.org/) useful.  The
Google cache contains most web but only lasts a month or two and doesn't have
images.  The Internet Archive contains fewer pages, but has multiple versions of
each page, includes images, and has archives going back to 1996.

    
    

    
  
I think that searching an internet archive or cache site when the page is not
found should be a feature asked in another bug.
The issue of just having a page displaying an error instead of a popup is all
this bug is about. 
Other sugestions about searching archive.org or google.com sounds great to me
but they are a different issue and another bug should be filled for that.

    
    

    
  
Besides: Some users (including me) wouldn't like it searching automatically. I 
hate how IE does that!

    
    

    
  
*** Bug 183077 has been marked as a duplicate of this bug. ***

    
    

    
  
per #204, adam, do you need help from UI to get this approved?

    
    

    
  
This bug is a meta bug waiting for all other bugs to be fixed before the pref is
going to change. First and foremost I could do with an sr= for bug 156997 

    
  
Depends on: 189204

    
  
Depends on: 188795
Summary: Should use error page and not dialog for inaccessible pages  (placeholder) → Should use error page and not dialog for inaccessible pages  (placeholder) (http and networking errors handling in content area)

    
    

    
  
Bug 39098 could be worked around by disabling the ability to select content from
the error pages (if there is specific text that might be copied, then we could
reenable selection just for those elements).

    
    

    
  
Renaming to make clear that this is a meta bug. 
Summary: Should use error page and not dialog for inaccessible pages  (placeholder) (http and networking errors handling in content area) → meta bug - show error pages instead of dialogs for network errors

    
    

    
  
Possible bug with this feature:
It seems the History of the tab is often unavailable when a network error occurs
and these errors messages are displayed.

Feature request:
On address not found errors, the url is currently displayed as a string.
Would be nice,( if the chrome address has to stay in the url bar) to have a
textbox containing the problomatic url, so i can quickly modify the address.
This would be exceptionally usefull, as i tend to type in the different 
servers , and my typing is often dyslexic.

Lots of work Feature request:
Have drop down box of similar address from the history.

    
    

    
  
> It seems the History of the tab is often unavailable when a network
> error occurs and these errors messages are displayed.

I can't remember a time when that HASN'T been the case for me.  All history is
lost and the back button (naturally) is greyed out.

    
    

    
  
> All history is lost and the back button (naturally) is greyed out.

Correction.  You CAN still go back by clicking on the Go menu and selecting the
entry at the bottom for the site you were at before.  So, technically, history
is not lost.  However, neither the back button nor Go -> Back work - despite the
fact that previous URL information obviously does exit.

    
    

    
  
Please remember that this feature is also used by embeddors and features that 
are available in Mozilla may not be available or implemented in the same way 
that Mozilla does. Any solution to problems needs to take that into account. I 
know that Adam is aware of that but its a reminder to others working on the bug.

    
    

    
  
*** Bug 193559 has been marked as a duplicate of this bug. ***
Summary: meta bug - show error pages instead of dialogs for network errors → meta bug - show error pages instead of dialogs for network errors (show errors as a page in the content area)

    
  
Keywords: mozilla1.3

    
    

    
  
*** Bug 201869 has been marked as a duplicate of this bug. ***

    
    

    
  
I agree with everything written in comment #211
Especially the fact that I lose the URL is horrible. E.g. I type in a very long
URL and just because of on incorrect character in the domain name, it's all gone
and I have to type it all again. Going back to pop-ups is no solution either, as
I'm using tabs a lot and if the page doesn't load in a background tab, the URL
bar will be blank, so I lost the URL again. In both cases I have to start all over.

Someone wrote "In case the URL must be changed...". Is that so? Why is that so?
Why isn't it possible to display a page, but have a different URL in URL bar? Is
this some internal limitation of the current code?

    
  
Depends on: 204068

    
    

    
  
5/5 EDT triage: minusing topembed+ status.  Dropping this from the radar to
better focus on existing working set.
Keywords: topembed+ → topembed-

    
  
Keywords: nsbeta1

    
    

    
  
[Netscape® Communicator 4.8 : en-20020722]

This bug was already there: no '4xp', and probably no 'regression' (except for
comment 177...).


(While I'm at it:)
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4) Gecko/20030612]

Bug still there. (v1.4rc2)


    
  
Summary: meta bug - show error pages instead of dialogs for network errors (show errors as a page in the content area) → meta bug - show error pages instead of dialogs for network errors (placeholder page in the content area)

    
    

    
  
Adding bug 213757 as dependency. Any time a error page goes to load
(non-existent domain, typoed local file) Firebird now completely crashes. Back
to accursed popup error messages for me. Sort of makes the JS popup-window
blocker pointless, eh?
Depends on: 213757
Summary: meta bug - show error pages instead of dialogs for network errors (placeholder page in the content area) → meta bug - show error pages instead of dialogs for network errors (placeholder page in the content area) (http error pages)
No longer depends on: 213757

    
    

    
  
Heh.  That ended up being a dupe of bug 213912 which is now fixed.

    
    

    
  
Just a comment. I've been running with the current implementation of error pages
(1.4 Release) for a while. It's considerably better than popups, but the thing
of overwriting the location with the error URL is a killer. Often I type an
address, get it slightly wrong, press enter, the error URL overwrites it... have
to type it again.

I don't understand why a URL has to be involved at all. Can't the code rendering
the page just realise, OK there is an error, output this instead...?

    
    

    
  
Aaron: that's bug 157004, "Use original URL in history and URL bar when an error
page is generated".

    
    

    
  
Bug 212221 [XUL error pages do not play nicely with IM button in Addressbook]
shows another crash from the error pages.  It is not fixed by Bug 213912 (crash
with js in chrome).  It was filed almost 3 weeks ago, but still happens with a
20030728 build.

    
    

    
  
*** Bug 181476 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 215976 has been marked as a duplicate of this bug. ***

    
  
Depends on: 214949

    
    

    
  
In Mozilla 1.5, build ID: 2003091604 (Win 98), error pages are broken. I'm
getting "XML parsing error" instead of the error pages. Can't find the
regression bug yet.

    
    

    
  
> Can't find the regression bug yet.

It could be bug 219355 - which was fixed yesterday.

    
    

    
  
Thanks, Jason. That's right. Moz 1.5 RC1 doesn't have the problem.

    
    

    
  
This bug has gotten a bit too long and convoluted.

As time permits, I'm going to start working on shutting this bug down, and
create new bugs for the current issues. Right now, we have too many people
complaining that they want something we have (error pages to replace error
dialogs), but not much actual usage or development of the errors pages.

Here's the general changes.

1- Review this bug, related bugs, and marked duplicates. (This could take some time)
2- Create new bugs for: open issues (documentation for the pref, obvious
problems w/ the error pages, "issue" bugs for each error TYPE (home for the
dupes), and changing the default pref value.
3- Close out this bug w/ a EOL-style summary and instructions on where to go for
particular issues.

I've done this in the past w/ PAC and several other issues that went too long,
and overall it worked well in restarting the more useful contributor activity.

If you want to discuss this or give me feedback, email me directly.

    
    

    
  
The Shuttleworth Foundation are offering a $500 'bounty' to be shared equally
between the team of people who fix these bugs, including work already done.

See the bottom of http://www.markshuttleworth.com/bounty.html for more info.

    
    

    
  
The bounty thing made me realize that Mozilla.org could use a bounty system for
more specific donations: see bug 227382 "Bounty system hosted by Mozilla.org"

<offtopic>If a 0 were added to the end of that $500, I'd suddenly become very
interested (But others would probably fix them before I got a chance) ;-)
</offtopic>

    
    

    
  
The bounty implies fixing bug 74331 as well (or instead of?).(added to dependancy).

Depends on: 74331

    
  
Depends on: 229737

    
    

    
  
*** Bug 229907 has been marked as a duplicate of this bug. ***

    
    

    
  
A nice addition is (what i miss in practicly all browsers) a cross reference
with the page not found and the cache. For example:

slahsdot.org -> alert("page not found!")

- or -

slahsdot.org -> Error: page not found (404). (and on the page itself: )
<hr>This page was not found. Do you want to try these links?<br>
http://slashdot.org<br>
http://bsd.slashdot.org<br>
<hr>Or retry this page (press F5 or click below)<br>
http://slahsdot.org<br>

An additional little nifty algortim wich changes .ne/tnieuws to .net/nieuws and
more of those more 'common' typo's would be nice as well, and probably not even
that complicated.

    
    

    
  
What i still miss (in practicly every browser on the planet) is a cross
reference from the broken link with the cache. This is what i now get:

slahsdot.org -> alert("not found! argh!");

And what i would like to see is something like this:

slahsdot.org -> error page, with in his contents:
<hr>Page not found<br>
The page was not found, do you want to try on of the following links?<br>
http://slashdot.org<br>
http://bsd.slashdot.org<br>
<hr>Or retry this link (hit F5 or click <a href=http://slahsdot.org>here</a><br>

A little nifty algoritm should be great here as well, something that changes
things like .ne/tnews to .net/news, etc. It isn't probabley that complicated,
but greatly increases the 'fun' of error pages ;)

    
    

    
  
Great, do i retype the complete story (browser didn't continue loading), are
they BOTH here :/

    
    

    
  
*** Bug 213750 has been marked as a duplicate of this bug. ***

    
  
Depends on: 237244

    
  
Depends on: 226401

    
    

    
  
*** Bug 249997 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 263471 has been marked as a duplicate of this bug. ***

    
    

    
  
removing bug 74331 from the list... it seems rather unrelated (except that
fixing this bug would make that one less of an issue)
No longer depends on: 74331

    
  
No longer blocks: 159324
Alias: errorpages
No longer depends on: 277658

    
    

    
  
pref("browser.xul.error_pages.enabled", false);
isn't this good enough to be set enable by default?


    
    

    
  
(In reply to comment #279)
> pref("browser.xul.error_pages.enabled", false);
> isn't this good enough to be set enable by default?
> 

Imho, for trunk builds, the remaining open blocking bugs don't seem important
enough to prevent what you're suggesting, except for bug 157004. But the latter
seems correctly fixed too on FF 20050221 (the "alternating url" problem
described in https://bugzilla.mozilla.org/show_bug.cgi?id=157004#c85 is WFM).
But this option is still not good enough for final releases.

    
  
Blocks: 256828

    
  
Depends on: 285674

    
  
Depends on: 285675

    
  
No longer depends on: 285675

    
    

    
  
*** Bug 286973 has been marked as a duplicate of this bug. ***

    
    

    
  
(In reply to comment #279)
> pref("browser.xul.error_pages.enabled", false);
> isn't this good enough to be set enable by default?

No. I've been using this combined with the show failed url extension and it
still leaves much to be desied.

1) You need the show failed url extension to show in the address bar the url of
the page you were trying to get to, otherwise it shows the address of the error
page in chrome:/// (and even with the extension, showing the url doesn't always
work). And that makes it tedious to try to reload the page.

2) Having these error pages enabled breaks the use of the back button, either by
"forgetting" the page you were on previously (the back button becomes greyed out
and you can't get back to where you were, even with alt-left arrow) or by taking
you back *two* pages rather than one.

    
    

    
  
(In reply to comment #282)
> (In reply to comment #279)
> > pref("browser.xul.error_pages.enabled", false);
> > isn't this good enough to be set enable by default?
> 
> No. I've been using this combined with the show failed url extension and it
> still leaves much to be desied.

Aren't you referring to some very ancient state of things?
None of this is true anymore. I also believe that it's OK to try setting this on
by default.

    
    

    
  
(In reply to comment #283)
> (In reply to comment #282)
> > (In reply to comment #279)
> > > pref("browser.xul.error_pages.enabled", false);
> > > isn't this good enough to be set enable by default?
> > 
> > No. I've been using this combined with the show failed url extension and it
> > still leaves much to be desied.
> 
> Aren't you referring to some very ancient state of things?
> None of this is true anymore. I also believe that it's OK to try setting this on
> by default.


I am referring to the way FF1.0.2 behaves RIGHT NOW. TODAY. I would not
characterize that as an "ancient state of things."

    
    

    
  
(In reply to comment #284)
> I am referring to the way FF1.0.2 behaves RIGHT NOW. TODAY. I would not
> characterize that as an "ancient state of things."

What about some recent nightly or a build compiled from CVS source?

    
    

    
  
(In reply to comment #285)
> (In reply to comment #284)
> > I am referring to the way FF1.0.2 behaves RIGHT NOW. TODAY. I would not
> > characterize that as an "ancient state of things."
> 
> What about some recent nightly or a build compiled from CVS source?

It does seem the aviary's error pages handling is improved... though it took me
forever to find that out since I wanted to use a clean profile and its profile
manager was buggy.

    
    

    
  
*** Bug 291486 has been marked as a duplicate of this bug. ***

    
    

    
  
I would like to suggest that the pop-up message that appears when a website
cannot be found is to be removed, or any other modal dialog. Instead the message
should appear in the same way that Firefox lets the user know that a pop-up from
a website has been blocked (the yellow bar at the top of a webpage).
This way the message does not interfere when the user has continued browsing in
another tab while the site is loading.
No more annoying pop-ups and no error-page that causes the url in the addressbar
to be overwritten.


    
    

    
  
> Instead the message should appear in the same way that Firefox lets
> the user know

What you're asking for would be a different bug, not this one.  File another bug
and propose it there.

> no error-page that causes the url in the addressbar to be overwritten.

This no longer happens in recent builds.

    
    

    
  
*** Bug 293170 has been marked as a duplicate of this bug. ***

    
    

    
  
IMHO, the NTNU (Norwegian university of science and technology) error pages
(http://www.ntnu.no/blah; source code at http://www.ntnu.no/error.phps) provide
some important usability clues:
- Display the actual error as H1 on the top of the page, not after a lot of
mumbo-jumbo "something went wrong",
- Separate the problem description and possible solutions
- Provide relevant links / forms
  - for "not found": a link to the domain with the rest of the URL stripped,
link to (Google) cache search, (Google) search form with "site:" as a hidden
part of the search string, (Google) search for links to the page
  - for "unauthorized"/"forbidden": a link to the domain with the rest of the
URL stripped
  - for "gone": link to (Google) cache search, (Google) search for links to the page

    
    

    
  
IMHO, the NTNU (Norwegian university of science and technology) error pages
(http://www.ntnu.no/blah; source code at http://www.ntnu.no/error.phps) provide
some important usability clues:
- Display the actual error as H1 on the top of the page, not after a lot of
mumbo-jumbo "something went wrong",
- Separate the problem description and possible solutions
- Provide relevant links / forms
  - for "not found": a link to the domain with the rest of the URL stripped,
link to (Google) cache search, (Google) search form with "site:" as a hidden
part of the search string, (Google) search for links to the page
  - for "unauthorized"/"forbidden": a link to the domain with the rest of the
URL stripped
  - for "gone": link to (Google) cache search, (Google) search for links to the page

    
    

    
  
I read through the entire additional comments section and I haven't seen a
single person mention the fact that if you were to navigate to a nonexistent
page with XUL pages enabled, it nukes the page history! If you press "Go", it
will try reloading the page, if you press "Refresh", it will open the previous
page. This is applicable for "The address (URL) does not correspond to a known
site and could not be loaded," as in typing in http://www.9a8wybrawruadjkds.com/

Why hasn't anyone mentioned this (because when things seem stupid, assume that
you're missing something), and is there a corresponding bug for this?

    
    

    
  
(In reply to comment #294)
> I read through the entire additional comments section and I haven't seen a
> single person mention the fact that if you were to navigate to a nonexistent
> page with XUL pages enabled, it nukes the page history!

In my experience, it only loses the history when there is only one page in the
history (e.g. you open your browser, the home page loads, and then you go to a
non-existant page). If your history consists of more than one page, the history
remains, but if you hit the back button it goes back 2 pages instead of one. If
you then hit the forward button it goes back to the last page you had up before
you went to the non-existent page.

This experience sounds, however, consistent with yours. It appears that when FF
goes tries to go to a non-existent page and brings up the XUL error page, it
actually believes it is still at the previous page it was on. This would explain
all of this aberrant behaviour.

    
    

    
  
can you people use non-ancient builds before complaining about fixed issues
here? (I'm assuming you are using FF 1.0.x or mozilla 1.7.x)

    
    

    
  
(In reply to comment #296)
> can you people use non-ancient builds before complaining about fixed issues
> here? (I'm assuming you are using FF 1.0.x or mozilla 1.7.x)

I don't understand what you're trying to say.

I am using Firefox build 1.0.4 (a quite non-ancient build, unless you count
development builds). I still have this problem. I'm trying to find out whether
or not there's another bug report for this related behavior for the patch
(because this problem is directly created by the patch). 

    
    

    
  
(In reply to comment #296)
> can you people use non-ancient builds before complaining about fixed issues
> here? (I'm assuming you are using FF 1.0.x or mozilla 1.7.x)

Wait... ::rereads comment:: Does that mean it's fixed in FF 1.1?

if($fixed == true) { do_happy_dance(); }

    
    

    
  
yeah. firefox 1.1 uses a gecko that's more than a year old. that bug is fixed in
current builds (in bug 157004, I believe)

I very much count development builds.

    
    

    
  
(In reply to comment #299)
> yeah. firefox 1.1 uses a gecko that's more than a year old. that bug is fixed in
> current builds (in bug 157004, I believe)
> 
> I very much count development builds.

Sorry to spam those who know it already... But I think biesi wanted to say
"firefox 1.0.x" instead of "firefox 1.1" above.
Please do _not_ add comments about "old" builds (not-trunk, in this case Firefox
1.0.x or Mozilla 1.7.x) on bugs talking about features that aren't even
completely finished yet. That only makes the comments list longer and doesn't
help fixing the bug. Only report problems on trunk (nightly) builds please.

    
    

    
  
Okay, I took a look at the 2005-05-14 official nightly build with a new profile
and I tested my problem, and it turned out, lo and behold, same thing!

Reproducible: Always
Steps:
1. Surf a bit, and get a few pages in your history.
2. Now, type in an obviously bosh URL (like http://www.a892jk3rs9aesae.com )
3. Take a look at the XUL page
4. Press Back

Expected Result: You return to page you were before you typed in the bogus URL

Actual Result: You return two pages back

Alternately, you can retest number 4 this way:

4. Press Refresh

Expected Result: You retry a connection to the bosh

Actual Result: You go back to the page you had before you typed in the bosh URL.

Does this merit another bug? Can anyone verify?

    
    

    
  
(In reply to comment #301)
You were using an aviary build, this bug is fixed on the trunk build (available
here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/).
The trunk versions end with a "+".

    
    

    
  
*** Bug 295598 has been marked as a duplicate of this bug. ***

    
  
No longer blocks: majorbugs
Blocks: 292510

    
    

    
  
Please implement a feature in Mozilla to turn off the pop-up window "The
document contains no data", so that it doesn't disrupt web-surfing. On many
sites, I'll get 3 or 4 of these errors in a row, so I have to stop what I'm
doing and click OK to each one, which becomes tedious.

    
    

    
  
Please implement a feature in Mozilla to turn off the pop-up window "The
document contains no data", so that it doesn't disrupt web-surfing. On many
sites, I'll get 3 or 4 of these errors in a row, so I have to stop what I'm
doing and click OK to each one, which becomes tedious.

    
    

    
  
(In reply to comment #305)
> Please implement a feature in Mozilla to turn off the pop-up window "The
> document contains no data", so that it doesn't disrupt web-surfing. On many
> sites, I'll get 3 or 4 of these errors in a row, so I have to stop what I'm
> doing and click OK to each one, which becomes tedious.

Please read the comments and take a look at the blocking bugs before you post
additional comments. So you would see that the modal dialog box is covered in
bug 216466.

    
  
Depends on: 298657

    
    

    
  
Removed or corrected dependencies:

depends on: 157527->199360 159071 160548->157004 161276 189204 226401 285674

Blocks: 74987 104166 126906->88810 154414 160423

not sure about bug 92997
No longer blocks: 74987, 104166, 126906, 154414, 160423
Depends on: 199360
No longer depends on: 157527, 159071, 160548, 161276, 189204, 226401, 285674

    
  
Flags: blocking-aviary1.1?

    
    

    
  
knocking this off the blocker list, we've already turned these on for Deer Park
Alpha 2
Flags: blocking-aviary1.1?

    
    

    
  
I also use a hosts file to block adware/ads, no real problems except when I
click on a link sent to me by eBay from an automated search. All of their links
go to doubleclick first. All I get when I click on it is a copy of Firefox with
a dialogue telling me it can't be found. Fair enough. But what it doesn't do is
to put the URL I originally requested into the address bar so I can remove the
doubleclick redirection off it. IE does this, but also displays an error page
(which I set to unbeautified - as I want to know what's really going on!), oh,
BTW - why can't you turn off case detection for keyboard shortcuts, especially
ALT+d works, but ALT+D doesn't. I've also just noticed that ALT+d seems to
select the first text box on this page...

    
    

    
  
II am using Mozilla Firefox 1.5 beta 1 and confirm that I no longer receive the
"this document contains no data" dialog box when I visit error-prone websites. 

    
    

    
  
I'm assuming that the "Show Failed URL" extension is no longer needed for 1.5b1?
Also, what about that "going back 2 pages" bug?  What is the status of this now
that 1.5b1 is out?

    
    

    
  
*** Bug 8345 has been marked as a duplicate of this bug. ***
No longer blocks: 8345

    
    

    
  
Just to throw in my 2 cents, 

"413 Request Entity Too Large" also returns "document contains no data"... I had to break out the packet sniffer which gave me more useful messages than firefox did.

For people uploading things to our web upload, if they are behind a bad proxy it would be useful if they knew what the problem was, rather than such a generic error.

    
    

    
  
To amend my message for Firefox 1.5, it now gives a generic error page "The connection was reset"...  For 413 Request Entity Too Large.

Still leaves out useful information the server told you!  Not much better than the old pop-up IMHO.

    
    

    
  
The URL "http://;" gives a "The URL is not valid and cannot be loaded." error dialog box in firefox 1.5. Ideally it would give an error page, not an error dialog box. Not sure if this falls under this bug or not.

    
    

    
  
The new "URL Broken" dialog in 1.5.0.5 is not an improvement. It rather defeats the purpose of the error_page machanism.

    
    

    
  
(In reply to comment #317)
This isn't really new, it's since 04/2005. See bug 291876 (and bug 312680 about what you tell).

    
    

    
  
(In reply to comment #318)
> (In reply to comment #317)
> This isn't really new, it's since 04/2005. See bug 291876 (and bug 312680 about
> what you tell).
> 

Thanks. 312680 describes the problem, though the circumstances under which I see it may be different.
1.5.0.6 is out; if the problem persists, I'll add something over there.

    
  
Depends on: 351578

    
    

    
  
(In reply to comment #22)
> Another big advantage of error page is that it would always be possible to ask
> Mozilla to retry the problematic URL just by pressing "Reload". With dialog,
> there does not seem to be a way to retry the communication. 

I don't see why you couldn't send the error code -and- the URL of the offending page to the dialog box and have the choices:  [cancel][try again]

The problem with error pages:  The page I want is mostly text, but has some advertising around the edges (which I don't care to see) which aren't loading, or are loading slowly.  I'm reading the text when all of a sudden I'm looking at a gray error page with a 'try again' button in the middle, and the page I was reading has disappeared.  If I hit 'try again' (especially if the text on the page is a long article) I have to wait until the part I was reading gets reloaded, scroll back down to find my place, and still I'll get redirected to this error page because the ads still aren't loading.  

With a dialog box, I can hit cancel, and continue reading the important parts.
 
> Yet another advatnage is that the error page can be save and/or e-mailed (for
> example to report the error to the server admin), while dialog can not.

So have a third option on the dialog box to open an error page in a new tab.

> I can attest that error pages are
> infinetely more convenient and easy to deal with. 

And I can attest they aren't.  Besides, I've always hated IE type error pages.

If I liked IE, I'd use it.  IE is a Virus.

    
    

    
  
Isn't this resolved long ago? The last comment is 5 years old!

    
    

    
  
This is a meta bug and not all of the dependencies are resolved.  Especially bug 157531 which was reopened.

    
  
Depends on: 309332
No longer depends on: 351578

    
  
Depends on: 313519
No longer depends on: 309332

    
  
Depends on: 451250
Assignee: adamlock → nobody
QA Contact: benc → docshell

    
    

    
  
This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.
Status: ASSIGNED → NEW
Depends on: 567362

    
  
Depends on: 569142

    
    

    
  
Added depends on bug 569142: show error page instead of reloading when
navigating session history to a page that was not stored.  The worst case of
bug 569142 was mentioned here way back in comment 8 (reload POST results
invokes the modal and generally lousy POSTDATA dialog of bug 160144).

    
    

    
  
Who is this fubugboys, and why was he able to remove others from the Cc: list of this bug?

    
    

    
  
I'm guessing he's exploiting a bug in bugzilla, and having some fun with it...

    
    

    
  
Status on this?
No longer depends on: 567362

    
    

    
  
I suspect this can be closed despite open dependencies, but sending over to Networking for confirmation.


Component: DOM: Navigation → Networking
Summary: meta bug - show error pages instead of dialogs for network errors (placeholder page in the content area) (http error pages) → [meta] meta bug - show error pages instead of dialogs for network errors (placeholder page in the content area) (http error pages)

    
    

    
  
(In reply to Henri Sivonen (:hsivonen) (away from Bugzilla until 2021-01-11) from comment #328)




I suspect this can be closed despite open dependencies, but sending over to Networking for confirmation.




I tend to agree.  I think bug 157531 may have been fixed too.


Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: