Last Comment Bug 28586 - (errorpages) meta bug - show error pages instead of dialogs for network errors (placeholder page in the content area) (http error pages)
(errorpages)
: meta bug - show error pages instead of dialogs for network errors (placeholde...
Status: NEW
[Hixie-P0][Hixie-1.0][wgate][MB]
: embed, helpwanted, meta, topembed-
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: Trunk
: All All
: P3 enhancement with 211 votes (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 8345 25618 43266 48850 55788 57867 68325 78896 82947 86658 88708 89252 91469 92524 97641 100135 103962 107252 111739 111904 112598 113093 114722 117279 124086 124145 124420 127264 127598 131215 136889 138411 143523 147203 147329 147602 149978 150549 151075 152687 155600 165340 166343 174911 175704 177353 183077 184168 193559 201869 213750 215976 229907 249997 263471 286973 293170 295598 (view as bug list)
Depends on: 157531 225695 273968 285055 313519 567362 39098 156997 157004 157102 188795 199360 204068 212221 214949 215753 216466 229737 237244 277658 280190 282050 290219 291876 298657 451250 569142
Blocks: 84128 121209 259741 292510 61685 88810 advocacybugs 96887 181083 256828 266619
  Show dependency treegraph
 
Reported: 2000-02-19 22:55 PST by Matthew Paul Thomas
Modified: 2014-10-18 07:05 PDT (History)
243 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch for docshell and webshell (3.89 KB, patch)
2001-10-29 16:37 PST, Martin Enlund
no flags Details | Diff | Splinter Review
Error page (933 bytes, text/plain)
2001-10-29 16:38 PST, Martin Enlund
no flags Details
Error page javascript (2.11 KB, text/plain)
2001-10-29 16:39 PST, Martin Enlund
no flags Details
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)
2001-10-30 10:42 PST, RC
no flags Details
Patch for docshell and webshell (5.94 KB, patch)
2002-02-17 14:32 PST, Aleksey Nogin
no flags Details | Diff | Splinter Review
Error page (996 bytes, text/plain)
2002-02-17 14:38 PST, Aleksey Nogin
no flags Details
Error page javascript (2.19 KB, text/plain)
2002-02-17 14:43 PST, Aleksey Nogin
no flags Details
Patch for docshell and webshell (5.73 KB, patch)
2002-02-27 15:45 PST, Martin Enlund
no flags Details | Diff | Splinter Review
A page that IE generates for not finding a site. (2.22 KB, text/html)
2002-03-12 01:05 PST, [not reading bugmail]
no flags Details
Work in progress (32.55 KB, patch)
2002-05-28 14:04 PDT, Adam Lock
no flags Details | Diff | Splinter Review
More work in progress (41.16 KB, patch)
2002-05-29 12:29 PDT, Adam Lock
no flags Details | Diff | Splinter Review
Patch (42.18 KB, patch)
2002-06-06 11:45 PDT, Adam Lock
radha: review+
rpotts: superreview+
Details | Diff | Splinter Review
Updated patch (43.04 KB, patch)
2002-07-10 10:59 PDT, Adam Lock
adamlock: review+
adamlock: superreview+
asa: approval+
Details | Diff | Splinter Review

Description Matthew Paul Thomas 2000-02-19 22:55:26 PST
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
Comment 1 Richard Zach 2000-02-19 23:09:32 PST
Good idea.  This should probably go to Networking, CC: UI.
Comment 2 Warren Harris 2000-02-22 00:05:15 PST
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. 
Comment 3 Warren Harris 2000-04-06 16:12:37 PDT
Moving to M17 (also beta2).
Comment 4 leger 2000-05-17 10:27:40 PDT
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?
Comment 5 leger 2000-05-17 10:44:16 PDT
Spoke with valeski - Putting on [nsbeta2-] radar. Not critical to beta2.
Comment 6 Matthew Paul Thomas 2000-06-21 20:49:53 PDT
*** Bug 43266 has been marked as a duplicate of this bug. ***
Comment 7 Jason Eager 2000-06-27 21:15:17 PDT
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!
Comment 8 Matthew Paul Thomas 2000-07-11 05:48:20 PDT
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.
Comment 9 Jason Eager 2000-07-11 20:32:16 PDT
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.
Comment 10 Jason Eager 2000-07-11 20:34:03 PDT
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. :-) )
Comment 11 Jesse Ruderman 2001-01-23 02:13:42 PST
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.
Comment 12 Keyser Sose 2001-02-17 14:38:38 PST
*** Bug 68325 has been marked as a duplicate of this bug. ***
Comment 13 S P Arif Sahari Wibowo 2001-02-19 09:25:43 PST
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!
Comment 14 timeless 2001-02-19 15:48:31 PST
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
Comment 15 Matthew Paul Thomas 2001-02-23 10:06:33 PST
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.
Comment 16 Aleksey Nogin 2001-02-23 10:16:18 PST
I agree with Matthew.
Comment 17 Greg K. 2001-04-05 16:58:24 PDT
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.
Comment 18 Keyser Sose 2001-04-26 18:11:36 PDT
*** Bug 70846 has been marked as a duplicate of this bug. ***
Comment 19 Boris Zbarsky [:bz] 2001-05-04 10:52:40 PDT
*** Bug 78896 has been marked as a duplicate of this bug. ***
Comment 20 benc 2001-05-10 11:23:03 PDT
qa to me.
Comment 21 j13moh 2001-05-15 13:45:31 PDT
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.
Comment 22 Aleksey Nogin 2001-05-15 14:13:04 PDT
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.
Comment 23 Jeremy M. Dolan 2001-05-15 14:24:39 PDT
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...
Comment 24 martin 2001-05-15 15:47:55 PDT
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.
Comment 25 Greg K. 2001-05-15 15:59:08 PDT
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).
Comment 26 Aleksey Nogin 2001-05-15 18:53:45 PDT
Even if it's just a link that I've clicked on, I still want to see the error
page, not a dialog.
Comment 27 Aleksey Nogin 2001-05-16 09:56:42 PDT
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.
Comment 28 Matthew Paul Thomas 2001-05-17 09:43:25 PDT
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.
Comment 29 benc 2001-05-17 14:14:44 PDT
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).
Comment 30 Matthias Versen [:Matti] 2001-05-27 11:55:09 PDT
*** Bug 82947 has been marked as a duplicate of this bug. ***
Comment 31 Alex Bishop 2001-06-07 10:46:17 PDT
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).
Comment 32 Randell Jesup [:jesup] 2001-06-13 10:12:14 PDT
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.
Comment 33 Alex Bishop 2001-06-19 10:38:27 PDT
*** Bug 86658 has been marked as a duplicate of this bug. ***
Comment 34 R.K.Aa. 2001-07-01 20:52:38 PDT
*** Bug 88708 has been marked as a duplicate of this bug. ***
Comment 35 David Härdeman 2001-07-04 12:51:39 PDT
*** Bug 89252 has been marked as a duplicate of this bug. ***
Comment 36 Jacek Piskozub 2001-07-06 10:29:59 PDT
Marking mostfreq at 10 bugs.
Comment 37 Ahmet A. Akin 2001-07-13 00:23:17 PDT
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. 
Comment 38 Francisco León 2001-07-20 08:20:09 PDT
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
Comment 39 Brian Mastenbrook 2001-07-27 06:41:45 PDT
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.
Comment 40 Alex Bishop 2001-07-27 08:20:54 PDT
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.
Comment 41 Cesar Eduardo Barros 2001-07-27 17:08:24 PDT
[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.
Comment 42 Alex Bishop 2001-07-28 09:49:38 PDT
<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>
Comment 43 Ben Bucksch (:BenB) 2001-08-06 23:04:15 PDT
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.)
Comment 44 Greg K. 2001-08-21 18:44:50 PDT
Resuggesting via keyword from an already-gone milestone to a realistic future one.
Comment 45 Tim Hill 2001-08-23 02:03:41 PDT
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.
Comment 46 Jonas Sicking (:sicking) PTO Until July 5th 2001-08-24 06:03:09 PDT
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.
Comment 47 Greg K. 2001-08-25 12:20:09 PDT
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?
Comment 48 Greg K. 2001-08-25 19:53:49 PDT
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.
Comment 49 Matthew Paul Thomas 2001-09-02 02:00:28 PDT
*** Bug 92524 has been marked as a duplicate of this bug. ***
Comment 50 Neil Munro 2001-09-02 02:28:55 PDT
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.

Comment 51 Ben Bucksch (:BenB) 2001-09-02 02:48:04 PDT
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.
Comment 52 Jesse Ruderman 2001-09-07 19:43:50 PDT
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>
Comment 53 Matthias Versen [:Matti] 2001-09-08 01:04:13 PDT
*** Bug 98831 has been marked as a duplicate of this bug. ***
Comment 54 Michael Hearn 2001-09-19 10:08:49 PDT
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
Comment 55 Ben Bucksch (:BenB) 2001-09-19 10:23:05 PDT
> That XML is then transformed by Transformiix

Transformixx is optional, you can't use it for such a central function.
Comment 56 Jesse Ruderman 2001-09-21 17:49:20 PDT
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.
Comment 57 Michael Hearn 2001-09-22 09:25:58 PDT
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?
Comment 58 Ben Bucksch (:BenB) 2001-09-22 10:27:38 PDT
> 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.
Comment 59 Hixie (not reading bugmail) 2001-09-26 11:10:22 PDT
Time to move it to components/ then...
Comment 60 Jesse Ruderman 2001-10-09 15:52:23 PDT
*** Bug 91469 has been marked as a duplicate of this bug. ***
Comment 61 Greg K. 2001-10-09 19:59:46 PDT
*** Bug 103962 has been marked as a duplicate of this bug. ***
Comment 62 Jesse Houwing 2001-10-10 03:40:47 PDT
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.
Comment 63 [not reading bugmail] 2001-10-14 06:44:07 PDT
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 
Comment 64 rob 2001-10-14 11:01:51 PDT
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.
Comment 65 [not reading bugmail] 2001-10-16 02:07:05 PDT
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?

Comment 66 Jesse Ruderman 2001-10-16 15:54:47 PDT
cuz84d: you're looking for bug 80293, a console for networking errors.  This 
bug is for placeholder pages.
Comment 67 [not reading bugmail] 2001-10-17 03:36:44 PDT
ok, its close.. but I'll head over to it.  
Comment 68 S P Arif Sahari Wibowo 2001-10-23 08:01:44 PDT
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.
Comment 69 Alex Bishop 2001-10-23 08:34:07 PDT
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.
Comment 70 benc 2001-10-23 10:17:22 PDT
Console suggestions should go to bug 80293.
Comment 71 [not reading bugmail] 2001-10-24 15:19:37 PDT
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
Comment 72 Boris Zbarsky [:bz] 2001-10-28 12:36:43 PST
*** Bug 107252 has been marked as a duplicate of this bug. ***
Comment 73 Martin Enlund 2001-10-29 16:37:50 PST
Created attachment 55657 [details] [diff] [review]
Patch for docshell and webshell
Comment 74 Martin Enlund 2001-10-29 16:38:49 PST
Created attachment 55659 [details]
Error page
Comment 75 Martin Enlund 2001-10-29 16:39:19 PST
Created attachment 55660 [details]
Error page javascript
Comment 76 Martin Enlund 2001-10-29 16:41:20 PST
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
Comment 77 Christian Reis 2001-10-29 17:29:42 PST
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
Comment 78 Neil Marshall 2001-10-29 19:17:31 PST
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.
Comment 79 Martin Enlund 2001-10-29 23:55:00 PST
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).
Comment 80 RC 2001-10-30 10:42:11 PST
Created attachment 55758 [details]
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?
Comment 81 Francisco León 2001-10-30 11:02:40 PST
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.
Comment 82 Jesse Ruderman 2001-10-30 11:04:18 PST
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.
Comment 83 benc 2001-10-30 11:21:42 PST
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.
Comment 84 S P Arif Sahari Wibowo 2001-11-02 08:11:15 PST
==== 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.
Comment 85 Greg K. 2001-11-02 09:37:56 PST
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.
Comment 86 Alex Bishop 2001-11-02 10:18:53 PST
Don't images produce an error message if they come from a third-party server?
Comment 87 Greg K. 2001-11-02 10:27:45 PST
No. Please review my comments of 2001-05-15 15:59 on this bug.
Comment 88 Martin Enlund 2001-11-05 05:29:47 PST
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?


Comment 89 Jesse Ruderman 2001-11-23 18:59:06 PST
*** Bug 100135 has been marked as a duplicate of this bug. ***
Comment 90 [not reading bugmail] 2001-11-24 00:57:37 PST
Martin, dont know who knows that info, maybe Blake, he knows the XUL and stuff.. 
Comment 91 R.K.Aa. 2001-11-24 13:09:25 PST
*** Bug 111739 has been marked as a duplicate of this bug. ***
Comment 92 alanjstr 2001-11-24 19:33:57 PST
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.  
Comment 93 [not reading bugmail] 2001-11-26 03:46:39 PST
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!!!! 

Comment 94 [not reading bugmail] 2001-11-26 03:49:54 PST
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/

Comment 95 Boris Zbarsky [:bz] 2001-12-01 18:07:21 PST
*** Bug 113093 has been marked as a duplicate of this bug. ***
Comment 96 Boris Zbarsky [:bz] 2001-12-11 13:50:38 PST
*** Bug 114722 has been marked as a duplicate of this bug. ***
Comment 97 amutch 2001-12-18 06:20:20 PST
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.
Comment 98 Christian :Biesinger (don't email me, ping me on IRC) 2001-12-23 13:55:48 PST
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?
Comment 99 Vincent Lefevre 2001-12-23 14:48:20 PST
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.
Comment 100 Alfonso Martinez 2001-12-29 06:06:21 PST
*** Bug 117279 has been marked as a duplicate of this bug. ***
Comment 101 Felix Miata 2002-01-22 23:33:01 PST
"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.
Comment 102 [not reading bugmail] 2002-02-03 16:58:58 PST
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.
Comment 103 Olivier Cahagne 2002-02-07 00:44:29 PST
*** Bug 124086 has been marked as a duplicate of this bug. ***
Comment 104 Lincoln Ramsay 2002-02-07 01:12:02 PST
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
Comment 105 Alfonso Martinez 2002-02-07 12:30:49 PST
*** Bug 124145 has been marked as a duplicate of this bug. ***
Comment 106 Alfonso Martinez 2002-02-08 11:27:38 PST
*** Bug 124420 has been marked as a duplicate of this bug. ***
Comment 107 Brendan Eich [:brendan] 2002-02-15 18:50:26 PST
Gagan, darin, can you guys skim for content here and give advice on whether and
how to fix this bug?  Thanks.

/be
Comment 108 timeless 2002-02-16 18:14:24 PST
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.
Comment 109 Peter Bojanic 2002-02-17 11:42:09 PST
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.
Comment 110 Brendan Eich [:brendan] 2002-02-17 13:51:56 PST
The patch is old and full of evil tabs.  Can someone refresh it and make it all
righteous and good?

/be
Comment 111 Aleksey Nogin 2002-02-17 14:32:59 PST
Created attachment 69999 [details] [diff] [review]
Patch for docshell and webshell

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.
Comment 112 Aleksey Nogin 2002-02-17 14:38:50 PST
Created attachment 70000 [details]
Error page

Updated attachment 55659 [details] to be free of "evil tabs".
Comment 113 Aleksey Nogin 2002-02-17 14:43:04 PST
Created attachment 70001 [details]
Error page javascript

Updated attachment 55660 [details] to get rid of "evil tabs".
Comment 114 Christian :Biesinger (don't email me, ping me on IRC) 2002-02-17 14:49:54 PST
use NS_LITERAL_STRING instead of NS_ConvertASCIIToUCS2 for literals, that's much
faster if supported
Comment 115 Darin Fisher 2002-02-21 21:55:51 PST
-> docshell
Comment 116 [not reading bugmail] 2002-02-22 02:37:42 PST
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.
Comment 117 Tuukka Tolvanen (sp3000) 2002-02-22 09:50:11 PST
*** Bug 127264 has been marked as a duplicate of this bug. ***
Comment 118 Jesse Ruderman 2002-02-23 18:07:38 PST
*** Bug 112598 has been marked as a duplicate of this bug. ***
Comment 119 Matthias Versen [:Matti] 2002-02-24 17:50:19 PST
*** Bug 127598 has been marked as a duplicate of this bug. ***
Comment 120 amutch 2002-02-25 20:31:54 PST
Will this patch be compatible with embedding apps?
Comment 121 Conrad Carlen (not reading bugmail) 2002-02-26 08:08:46 PST
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?
Comment 122 Martin Enlund 2002-02-27 15:45:34 PST
Created attachment 71771 [details] [diff] [review]
Patch for docshell and webshell

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.
Comment 123 Christian :Biesinger (don't email me, ping me on IRC) 2002-03-01 14:24:37 PST
+    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="));

Comment 124 Austin Ziegler 2002-03-05 07:44:40 PST
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.
Comment 125 Andrew Hagen 2002-03-05 10:07:18 PST
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.
Comment 126 Asa Dotzler [:asa] 2002-03-06 22:55:04 PST
*** Bug 97641 has been marked as a duplicate of this bug. ***
Comment 127 Judson Valeski 2002-03-07 16:08:58 PST
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.
Comment 128 Boris Zbarsky [:bz] 2002-03-08 10:07:12 PST
*** Bug 129681 has been marked as a duplicate of this bug. ***
Comment 129 [not reading bugmail] 2002-03-12 01:05:11 PST
Created attachment 73647 [details]
A page that IE generates for not finding a site.

This is what you get if you hit IE's Stop button.. I'd say mozilla would look
good with something similar.
Comment 130 Raphael Wegmann 2002-03-12 09:02:07 PST
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").
Comment 131 Vadim Berezniker 2002-03-12 13:37:07 PST
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.
Comment 132 Alfonso Martinez 2002-03-15 10:50:53 PST
*** Bug 131215 has been marked as a duplicate of this bug. ***
Comment 133 benc 2002-03-26 19:29:26 PST
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..."

Comment 134 Chris 2002-03-26 19:40:27 PST
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 ;-)
Comment 135 benc 2002-03-26 21:37:46 PST
(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.)
Comment 136 [not reading bugmail] 2002-03-27 00:29:15 PST
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
Comment 137 Asa Dotzler [:asa] 2002-03-27 10:45:03 PST
Has patch, highly desired, useful for embedders. Adding mozilla1.0+ keyword to
see if we can find reviewers and testers.
Comment 138 Andrew Smith 2002-03-28 07:34:41 PST
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.
Comment 139 Ian Pottinger 2002-04-03 22:26:49 PST
adding self to cc list
Comment 140 Hixie (not reading bugmail) 2002-04-07 15:53:50 PDT
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?
Comment 141 Michael Lefevre 2002-04-11 11:58:14 PDT
*** Bug 136889 has been marked as a duplicate of this bug. ***
Comment 142 R.K.Aa. 2002-04-19 01:29:10 PDT
*** Bug 138411 has been marked as a duplicate of this bug. ***
Comment 143 Matthias Versen [:Matti] 2002-04-27 15:32:21 PDT
*** Bug 55788 has been marked as a duplicate of this bug. ***
Comment 144 Adam Lock 2002-04-29 06:19:17 PDT
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.
Comment 145 Matthias Versen [:Matti] 2002-05-10 13:17:13 PDT
*** Bug 143523 has been marked as a duplicate of this bug. ***
Comment 146 Dimitrios 2002-05-13 14:16:34 PDT
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 :-)).
Comment 147 Bert Knight 2002-05-14 20:36:51 PDT
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?
Comment 148 Felix Miata 2002-05-14 21:47:56 PDT
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.
Comment 149 Christian :Biesinger (don't email me, ping me on IRC) 2002-05-15 00:59:54 PDT
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.
Comment 150 Sören 'Chucker' Kuklau (gone) 2002-05-15 03:38:55 PDT
For the time being, I recommend bannerblind for you. http://bannerblind.mozdev.org/ 
Comment 151 Vincent Lefevre 2002-05-15 07:12:28 PDT
bannerblind doesn't solve the problem. URL: http://www.voyages-sncf.com/
So, this bug should really be fixed.
Comment 152 Jesse Houwing 2002-05-15 07:22:35 PDT
It does for me, just add the size of the banner to bannerblind and all is well.
Comment 153 Vincent Lefevre 2002-05-15 10:03:26 PDT
[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.
Comment 154 Greg K. 2002-05-15 10:08:47 PDT
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.
Comment 155 Adam Lock 2002-05-15 13:45:04 PDT
*** Bug 111904 has been marked as a duplicate of this bug. ***
Comment 156 Felix Miata 2002-05-15 14:15:01 PDT
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.
Comment 157 Bart van Bragt 2002-05-15 14:27:10 PDT
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.
Comment 158 Christian :Biesinger (don't email me, ping me on IRC) 2002-05-15 14:31:38 PDT
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.
Comment 159 Adam Lock 2002-05-15 14:40:11 PDT
Retargetting.

I'm looking at this at the moment.
Comment 160 Felix Miata 2002-05-15 14:50:22 PDT
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.
Comment 161 Vincent Lefevre 2002-05-15 14:54:52 PDT
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.
Comment 162 Adam Lock 2002-05-15 15:03:24 PDT
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.
Comment 163 rpotts (gone) 2002-05-15 21:43:57 PDT
*** Bug 111904 has been marked as a duplicate of this bug. ***
Comment 164 Chris 2002-05-15 22:24:39 PDT
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 ;-)
Comment 165 Malx 2002-05-16 03:05:02 PDT
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.
Comment 166 Vincent Lefevre 2002-05-16 04:43:59 PDT
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.
Comment 167 Brian 'netdragon' Bober 2002-05-20 02:02:29 PDT
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).
Comment 168 Aaron Kaluszka 2002-05-20 05:09:39 PDT
Re: comment 167
Many ads are not just images, but iframes.  Therefore, bug 41924 is irrelevant.
Comment 169 Boris Zbarsky [:bz] 2002-05-26 12:49:16 PDT
*** Bug 147203 has been marked as a duplicate of this bug. ***
Comment 170 Alfonso Martinez 2002-05-27 03:37:39 PDT
*** Bug 147329 has been marked as a duplicate of this bug. ***
Comment 171 Michael Lefevre 2002-05-28 08:24:31 PDT
*** Bug 147602 has been marked as a duplicate of this bug. ***
Comment 172 Adam Lock 2002-05-28 14:04:30 PDT
Created attachment 85306 [details] [diff] [review]
Work in progress

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.
Comment 173 Adam Lock 2002-05-29 12:29:04 PDT
Created attachment 85472 [details] [diff] [review]
More work in progress

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.
Comment 174 Jonas Sicking (:sicking) PTO Until July 5th 2002-05-29 14:54:44 PDT
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.
Comment 175 Wouter van Wijk 2002-06-04 05:03:17 PDT
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.
Comment 176 Sören 'Chucker' Kuklau (gone) 2002-06-04 05:10:28 PDT
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? :-)
Comment 177 Felix Miata 2002-06-04 05:24:55 PDT
> > 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.
Comment 178 Peter Trudelle 2002-06-04 08:32:27 PDT
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.
Comment 179 Paul Harrison 2002-06-04 08:46:10 PDT
> 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.
Comment 180 Chris Casciano 2002-06-04 09:04:32 PDT
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.
Comment 181 Peter Trudelle 2002-06-04 09:17:28 PDT
If a modal dialog is affecting other network activity, that would be a separate
defect, please file a separate bug.
Comment 182 Neil Marshall 2002-06-04 10:20:12 PDT
modal alert dialog in any window blocks necko for all windows
http://bugzilla.mozilla.org/show_bug.cgi?id=74331
Comment 183 Felix Miata 2002-06-05 17:43:40 PDT
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.
Comment 184 Brian 'netdragon' Bober 2002-06-05 22:19:25 PDT
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.
Comment 185 Christian :Biesinger (don't email me, ping me on IRC) 2002-06-06 02:25:15 PDT
mrmazda, yes, that is a bug, _but a seperate one_
Comment 186 Felix Miata 2002-06-06 06:05:15 PDT
If that is the case, then bug 126906 should not have been duped to bug 111904.
Bug 126906 reopened and probably depends on this.
Comment 187 Adam Lock 2002-06-06 11:45:35 PDT
Created attachment 86662 [details] [diff] [review]
Patch

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?
Comment 188 Greg K. 2002-06-06 11:57:01 PDT
Keyword changes: adding review; removing mozilla1.0+ since this obviously didn't
make it; adding mozilla1.1.
Comment 189 R.K.Aa. 2002-06-07 16:24:47 PDT
*** Bug 149978 has been marked as a duplicate of this bug. ***
Comment 190 Matthias Versen [:Matti] 2002-06-09 22:49:20 PDT
*** Bug 150549 has been marked as a duplicate of this bug. ***
Comment 191 Matthias Versen [:Matti] 2002-06-11 22:34:57 PDT
*** Bug 151075 has been marked as a duplicate of this bug. ***
Comment 192 Alfonso Martinez 2002-06-19 06:43:34 PDT
*** Bug 152687 has been marked as a duplicate of this bug. ***
Comment 193 Alfonso Martinez 2002-07-03 08:39:35 PDT
*** Bug 155600 has been marked as a duplicate of this bug. ***
Comment 194 amutch 2002-07-04 22:54:13 PDT
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 195 Radha on family leave (not reading bugmail) 2002-07-09 15:45:54 PDT
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 196 Radha on family leave (not reading bugmail) 2002-07-09 15:47:03 PDT
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 197 rpotts (gone) 2002-07-09 23:41:45 PDT
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 :-)
Comment 198 Conrad Carlen (not reading bugmail) 2002-07-10 07:29:39 PDT
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.
Comment 199 Adam Lock 2002-07-10 07:45:36 PDT
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.
Comment 200 Adam Lock 2002-07-10 10:59:20 PDT
Created attachment 90804 [details] [diff] [review]
Updated patch

Same as before with one makefile.win fix and the mac build changes at the end.
Still to verify on mac...
Comment 201 Adam Lock 2002-07-10 11:02:24 PDT
Comment on attachment 90804 [details] [diff] [review]
Updated patch

Carrying r/sr forward
Comment 202 Adam Lock 2002-07-10 13:18:25 PDT
Verifying patch works on win32, unix & mac.
Comment 203 Asa Dotzler [:asa] 2002-07-11 13:36:53 PDT
Comment on attachment 90804 [details] [diff] [review]
Updated patch

a=asa (on behalf of drivers) for checkin to the 1.1 trunk.
Comment 204 Adam Lock 2002-07-11 14:21:47 PDT
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.
Comment 205 Greg K. 2002-07-11 15:14:57 PDT
Adam, can that pref alternatively be put in user.js?
Comment 206 Adam Lock 2002-07-11 15:27:30 PDT
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.
Comment 207 Stephen Ostermiller 2002-07-12 07:26:18 PDT
I just filed a new bug introduced by this patch -
bug 157102: Back to error page crashes the browser.
Comment 208 amutch 2002-07-12 09:45:08 PDT
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.
Comment 209 Pete Collins (MDG) 2002-07-12 12:58:50 PDT
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

Comment 210 Pratik 2002-07-12 13:54:47 PDT
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.
Comment 211 Jesse Ruderman 2002-07-13 00:24:34 PDT
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.
Comment 212 Greg K. 2002-07-13 00:35:21 PDT
Is the idea to have the error pages in XHTML for now, and change them to XUL at
some point?
Comment 213 Adam Lock 2002-07-15 05:59:38 PDT
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.
Comment 214 Daniel Wang 2002-07-31 20:44:26 PDT
*** Bug 160423 has been marked as a duplicate of this bug. ***
Comment 215 Boris Zbarsky [:bz] 2002-08-29 02:39:06 PDT
*** Bug 165340 has been marked as a duplicate of this bug. ***
Comment 216 Jonas Jørgensen 2002-09-03 13:58:41 PDT
*** Bug 166343 has been marked as a duplicate of this bug. ***
Comment 217 Anthony Giorgio 2002-09-12 09:06:32 PDT
Has this patch been committed to the trunk?  I'm using 1.2a and I still get the
modal dialog.
Comment 218 Greg K. 2002-09-12 09:14:07 PDT
Anthony, you must add a hidden pref to enable it. See comment 210.
Comment 219 Jeremy M. Dolan 2002-09-26 14:23:00 PDT
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.

Comment 220 timeless 2002-09-26 14:32:27 PDT
that's bug 39098
Comment 221 benc 2002-10-01 18:28:00 PDT
*** Bug 25618 has been marked as a duplicate of this bug. ***
Comment 222 Boris Zbarsky [:bz] 2002-10-16 22:39:12 PDT
*** Bug 174911 has been marked as a duplicate of this bug. ***
Comment 223 Jesse Ruderman 2002-10-21 01:59:29 PDT
*** Bug 175704 has been marked as a duplicate of this bug. ***
Comment 224 Matthias Versen [:Matti] 2002-10-21 15:55:05 PDT
*** Bug 57867 has been marked as a duplicate of this bug. ***
Comment 225 Juan José Mata 2002-10-23 00:10:51 PDT
Update target milestone to 'Future' since this missed the 'mozilla1.1beta' train.
Comment 226 Jacek Piskozub 2002-10-23 09:16:53 PDT
Juan: Please, do not change the target field unless you are the bug owner.

Or unless he is dead... ;-)
Comment 227 Adam Lock 2002-10-23 10:02:13 PDT
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. 
Comment 228 saari (gone) 2002-10-25 09:36:22 PDT
topembed+ since this is one of those IE-ish things that some embeddors prefer. 
Comment 229 Boris Zbarsky [:bz] 2002-10-29 12:47:19 PST
*** Bug 177353 has been marked as a duplicate of this bug. ***
Comment 230 Tom Mraz 2002-11-01 14:47:55 PST
This can't make it to mozilla1.2. It needs to be tested in the alpha release.
Comment 231 benc 2002-11-01 15:43:44 PST
*** Bug 48850 has been marked as a duplicate of this bug. ***
Comment 232 Chris Lyon 2002-12-09 11:12:59 PST
*** Bug 184168 has been marked as a duplicate of this bug. ***
Comment 233 Chris Lyon 2002-12-09 12:12:31 PST
*** Bug 184489 has been marked as a duplicate of this bug. ***
Comment 234 Slava Antin 2002-12-10 02:45:39 PST
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
Comment 235 Jeremy M. Dolan 2002-12-10 10:08:40 PST
"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?)
Comment 236 Boris Zbarsky [:bz] 2002-12-11 09:26:39 PST
*** Bug 184841 has been marked as a duplicate of this bug. ***
Comment 237 Matthew Paul Thomas 2002-12-19 11:21:10 PST
*** Comment 234 has been marked as a duplicate of this bug. ***
Comment 238 Alberto Reyes 2003-01-03 11:08:21 PST
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.
Comment 239 Jesse Ruderman 2003-01-03 14:54:39 PST
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.
Comment 240 http://tinymailto.com/oliversl 2003-01-03 20:30:56 PST
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.
Comment 241 Brian 'netdragon' Bober 2003-01-03 23:35:58 PST
Besides: Some users (including me) wouldn't like it searching automatically. I 
hate how IE does that!
Comment 242 Michael Lefevre 2003-01-04 12:28:15 PST
*** Bug 183077 has been marked as a duplicate of this bug. ***
Comment 243 benc 2003-01-09 07:59:21 PST
per #204, adam, do you need help from UI to get this approved?
Comment 244 Adam Lock 2003-01-09 09:48:20 PST
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 
Comment 245 Hixie (not reading bugmail) 2003-01-29 16:04:00 PST
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).
Comment 246 Adam Lock 2003-01-30 09:05:33 PST
Renaming to make clear that this is a meta bug. 
Comment 247 Ivar Abrahamsen 2003-02-07 04:51:08 PST
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.
Comment 248 Jason Bassford 2003-02-07 05:15:20 PST
> 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.
Comment 249 Jason Bassford 2003-02-11 05:57:26 PST
> 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.
Comment 250 amutch 2003-02-11 07:02:12 PST
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.
Comment 251 Matthias Versen [:Matti] 2003-02-16 08:17:27 PST
*** Bug 193559 has been marked as a duplicate of this bug. ***
Comment 252 Boris Zbarsky [:bz] 2003-04-13 10:22:34 PDT
*** Bug 201869 has been marked as a duplicate of this bug. ***
Comment 253 TGOS 2003-04-24 01:53:46 PDT
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?
Comment 254 Juan José Mata 2003-05-05 10:28:20 PDT
5/5 EDT triage: minusing topembed+ status.  Dropping this from the radar to
better focus on existing working set.
Comment 255 Serge Gautherie (:sgautherie) 2003-06-18 15:32:19 PDT
[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)
Comment 256 Jeremy M. Dolan 2003-07-25 23:24:19 PDT
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?
Comment 257 Jason Bassford 2003-07-26 06:31:25 PDT
Heh.  That ended up being a dupe of bug 213912 which is now fixed.
Comment 258 Aaron Lawrence 2003-07-26 17:46:42 PDT
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...?
Comment 259 Jesse Ruderman 2003-07-26 18:53:19 PDT
Aaron: that's bug 157004, "Use original URL in history and URL bar when an error
page is generated".
Comment 260 Hanspeter Niederstrasser 2003-07-28 17:22:28 PDT
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.
Comment 261 Matthias Versen [:Matti] 2003-08-12 07:21:42 PDT
*** Bug 181476 has been marked as a duplicate of this bug. ***
Comment 262 Matthias Versen [:Matti] 2003-08-12 14:46:40 PDT
*** Bug 215976 has been marked as a duplicate of this bug. ***
Comment 263 Andrew Hagen 2003-09-18 20:27:13 PDT
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.
Comment 264 Jason Bassford 2003-09-18 21:13:21 PDT
> Can't find the regression bug yet.

It could be bug 219355 - which was fixed yesterday.
Comment 265 Andrew Hagen 2003-09-19 17:28:55 PDT
Thanks, Jason. That's right. Moz 1.5 RC1 doesn't have the problem.
Comment 266 benc 2003-09-26 07:48:07 PDT
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.
Comment 267 Ian Thomas ('thelem') 2003-12-03 04:54:28 PST
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.
Comment 268 Robert Accettura [:raccettura] 2003-12-03 06:05:28 PST
.
Comment 269 Brian 'netdragon' Bober 2003-12-03 10:22:18 PST
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>
Comment 270 Errol Smith 2003-12-04 17:06:23 PST
The bounty implies fixing bug 74331 as well (or instead of?).(added to dependancy).
Comment 271 R.K.Aa. 2004-02-15 03:09:34 PST
*** Bug 229907 has been marked as a duplicate of this bug. ***
Comment 272 Michael Meeuwisse 2004-02-20 06:45:38 PST
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.
Comment 273 Michael Meeuwisse 2004-02-20 06:52:45 PST
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 ;)
Comment 274 Michael Meeuwisse 2004-02-20 06:55:50 PST
Great, do i retype the complete story (browser didn't continue loading), are
they BOTH here :/
Comment 275 Asa Dotzler [:asa] 2004-03-02 17:34:31 PST
*** Bug 213750 has been marked as a duplicate of this bug. ***
Comment 276 Christian :Biesinger (don't email me, ping me on IRC) 2004-09-16 13:26:28 PDT
*** Bug 249997 has been marked as a duplicate of this bug. ***
Comment 277 Stefan Borggraefe 2004-10-08 05:59:09 PDT
*** Bug 263471 has been marked as a duplicate of this bug. ***
Comment 278 Christian :Biesinger (don't email me, ping me on IRC) 2004-11-01 15:31:46 PST
removing bug 74331 from the list... it seems rather unrelated (except that
fixing this bug would make that one less of an issue)
Comment 279 Bozhan Boiadzhiev 2005-02-24 18:34:15 PST
pref("browser.xul.error_pages.enabled", false);
isn't this good enough to be set enable by default?
Comment 280 Dimitrios 2005-02-24 22:46:51 PST
(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.
Comment 281 Ryan VanderMeulen [:RyanVM] 2005-03-20 15:24:16 PST
*** Bug 286973 has been marked as a duplicate of this bug. ***
Comment 282 Lisa 2005-03-26 05:52:04 PST
(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.
Comment 283 Radek 'sysKin' Czyz 2005-03-26 06:02:14 PST
(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.
Comment 284 Lisa 2005-03-26 06:29:50 PST
(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."
Comment 285 Jure Repinc (JLP) 2005-03-26 06:32:53 PST
(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?
Comment 286 Lisa 2005-03-26 07:06:35 PST
(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.
Comment 287 Christian :Biesinger (don't email me, ping me on IRC) 2005-03-26 07:10:31 PST
1.0.x is indeed ancient.
Comment 288 Matthias Versen [:Matti] 2005-04-22 10:57:05 PDT
*** Bug 291486 has been marked as a duplicate of this bug. ***
Comment 289 Johan van Ruth 2005-04-22 11:33:11 PDT
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.
Comment 290 Jason Bassford 2005-04-22 12:47:54 PDT
> 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.
Comment 291 Matthias Versen [:Matti] 2005-05-06 13:51:50 PDT
*** Bug 293170 has been marked as a duplicate of this bug. ***
Comment 292 Victor Engmark 2005-05-11 08:45:36 PDT
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
Comment 293 Victor Engmark 2005-05-11 08:48:50 PDT
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
Comment 294 Edward Z. Yang 2005-05-15 12:48:36 PDT
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?
Comment 295 Lisa 2005-05-15 14:09:45 PDT
(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.
Comment 296 Christian :Biesinger (don't email me, ping me on IRC) 2005-05-15 14:30:27 PDT
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)
Comment 297 Edward Z. Yang 2005-05-15 14:35:25 PDT
(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). 
Comment 298 Edward Z. Yang 2005-05-15 14:39:55 PDT
(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(); }
Comment 299 Christian :Biesinger (don't email me, ping me on IRC) 2005-05-15 14:51:46 PDT
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.
Comment 300 Robert Kaiser 2005-05-15 16:34:10 PDT
(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.
Comment 301 Edward Z. Yang 2005-05-16 16:53:26 PDT
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?
Comment 302 Thomas Bertels 2005-05-25 03:47:45 PDT
(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 "+".
Comment 303 Kevin Brosnan 2005-05-26 07:25:16 PDT
*** Bug 295598 has been marked as a duplicate of this bug. ***
Comment 304 Mark 2005-06-23 10:00:48 PDT
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.
Comment 305 Mark 2005-06-23 10:02:20 PDT
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.
Comment 306 Henrik Skupin (:whimboo) 2005-06-23 10:33:23 PDT
(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.
Comment 307 Thomas Bertels 2005-06-24 02:13:34 PDT
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
Comment 308 Mike Connor [:mconnor] 2005-07-11 00:42:34 PDT
knocking this off the blocker list, we've already turned these on for Deer Park
Alpha 2
Comment 309 David Hunt 2005-07-21 08:00:02 PDT
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...
Comment 310 Stephen Smith 2005-09-20 03:46:17 PDT
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. 
Comment 311 Dan Fischbach 2005-09-20 04:15:05 PDT
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?
Comment 312 Christian :Biesinger (don't email me, ping me on IRC) 2005-09-20 05:38:48 PDT
those bugs are fixed.
Comment 313 Wayne Mery (:wsmwk, NI for questions) 2005-11-28 11:39:36 PST
*** Bug 8345 has been marked as a duplicate of this bug. ***
Comment 314 Jason Giglio 2005-12-05 09:29:22 PST
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.
Comment 315 Jason Giglio 2005-12-05 09:36:32 PST
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.
Comment 316 Nick_Jenkins 2005-12-06 17:23:25 PST
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.
Comment 317 John Ralls 2006-07-30 21:11:14 PDT
The new "URL Broken" dialog in 1.5.0.5 is not an improvement. It rather defeats the purpose of the error_page machanism.
Comment 318 Thomas Bertels 2006-07-31 00:37:49 PDT
(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).
Comment 319 John Ralls 2006-08-02 21:02:02 PDT
(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.
Comment 320 Lythande 2006-11-26 03:18:06 PST
(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.
Comment 321 Gábor Stefanik 2007-05-31 15:03:39 PDT
Isn't this resolved long ago? The last comment is 5 years old!
Comment 322 alanjstr 2007-05-31 16:29:52 PDT
This is a meta bug and not all of the dependencies are resolved.  Especially bug 157531 which was reopened.
Comment 323 Michael Kohler [:mkohler] 2010-05-13 10:10:58 PDT
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.
Comment 324 Shad Sterling 2010-06-26 22:13:44 PDT
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).
Comment 325 Jens Müller (:tessarakt) 2011-04-20 07:20:18 PDT
Who is this fubugboys, and why was he able to remove others from the Cc: list of this bug?
Comment 326 Mark Slater 2011-04-20 07:23:25 PDT
I'm guessing he's exploiting a bug in bugzilla, and having some fun with it...

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