313519 - "Connection Interrupted" error-page should not replace page being rendered

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Sergio Del Franco]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050910 SeaMonkey/1.0a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050910 SeaMonkey/1.0a

Sometimes a page is bieng rendered and while i'm reading its contents the page is replaced with "Connection Interrupted" error-page.

Reproducible: Always

Steps to Reproduce:
(It's so difficult to reproduce because its not depends in user interaction but server reply)
Actual Results:  
Page being rendered is replaced with error page.

Expected Results:  
Ironically this error is better handled by old message box rather than error page.
I think a good way to solve it should be to render error "page" (message) inside the page being rendered, but this could be unperceptible by user if pag is too long (maybe user saves the page thinking it is complete). A firefox-like warning bar (similar to "blocked popup" o "missing plugin" ones) should be great (sadly, not a happy approach for SeaMonkey).

Comment 1

[Sergio Del Franco]

Attachment: Screenshot

Comment 2

[Scott MacGregor]

Comment on attachment 200547 [details]
Screenshot

not sure what you meant to do by nominating a screen shot.

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

This is a good point; if we've got half of the page, replacing it with an error message is probably not the most useful thing we can do for the user. I'm going to add this to the bucket of "network connection status" UE improvements that I'm exploring for Firefox 2. 

BTW, I'm not sure that "event handling" is the right component for this bug, since we're not changing the way the platform handles this event, just the way the front end notifies the user.

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

Product: Core -> Firefox
Version: trunk
Component: general

Comment 5

[Sergio Del Franco]

(In reply to comment #3)
> BTW, I'm not sure that "event handling" is the right component for this bug,
> since we're not changing the way the platform handles this event, just the way
> the front end notifies the user.

I was not sure if error page was a core behavior or an UI one.
I thought it was related to gecko because Firefox and SeaMonkey both do it the same way.
Thanks you for clarifying.

Comment 6

[zug_treno]

Related to bug 68408?

Comment 7

[Mike Connor [:mconnor]]

At the least, we can flip back to using the (ugh) dialog.  This is a fairly rare error so the notification shouldn't be THAT bad.

Comment 8

[Justin Kerk]

Something like the popup/plugin finder bar at the top would probably do the trick without being overly intrusive.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

I'm not sure that a browsermessage would be noticable enough considering the fact that -- presently -- the page load would be halted at an incomplete state. This seems to be a candidate for the status notification area piece that's targetted for Firefox 2 (see wiki.mozilla.org/Firefox:2.0_Product_Planning:Draft_Plan for details) as well as some of the online/offline enhancements targetted for Fx3.

As annoying as the popup error is, I think it might be neccessary to call the user's attention to the problem. I like the idea of a "Try Again" button on that message, though.

Comment 10

[Sergio Del Franco]

If this is a gecko bug, why not raise an error/event and let frontend do whatever it want? (replace with an error page, show a bar, show a popup, write to syslog, raise a BSoD, whetever).

Comment 11

[John A.]

This happens in SeaMonkey 1.0 as well, on both Win2000 and Win98. OS: All?

Most annoying, and definitely mucks things up. I had it happen on one page that would, if it were not replaced by the error message, have still had several links I could use to continue working/determine what happened/take corrective measures. As it is the message removes whatever clues I may have had as to what happened.

I agree with Comment #10: leave it up to the front end to decide how to present the error. It needs to be fixed ASAP, though, so if that's too complicated just revert to the old pop-up until the better solution is ready.

Comment 12

[John A.]

Workaround - seems to work in SeaMonkey 1.0...

user_pref("browser.xul.error_pages.enabled", false);

Comment 13

[Darin Fisher]

Not going to block FF2 beta1 for this, but we'll happily consider a patch for FF2 beta2.

Comment 14

[Jeff Walden [:Waldo]]

Temporarily investigating...

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

Waldo:

low-bar: revert to how we did this in 1.0, with a modal (ew) dialog (ick)
high-bar: use a <notificationmessage> that uses the same string ("The network link was interrupted ..." and button label ("Try Again")

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #15)
> low-bar: revert to how we did this in 1.0, with a modal (ew) dialog (ick)

Apparently we currently already do this for invalid URL errors, so we should be able to do this pretty easily.

Comment 17

[Mike Schroepfer]

Not going to block FF2 but would take a patch.  Dolske can you take a look?

Comment 18

[Justin Dolske [:Dolske]]

Hmm. So, this looks like it's probably just a matter of tossing in a simple flag to force an alert instead of an XUL message, around http://lxr.mozilla.org/mozilla1.8/source/docshell/base/nsDocShell.cpp#3064

However, I can't seem to recreate the problem to test with. Under what conditions is this error generated?

I've rigged up a dummy HTTP server to simulate connections dropping in various ways (normal TCP FIN, RST, Content-Length or not, ...) and at various points in the session. FF 1.5 and 2.0b2 both act the same way...

If the connection closes normally (4-way FIN), the browser will either display a blank page or whatever partial content was returned. If the connection is dropped with a RST packet, the browser displays a "The connection was reset" page if it was interrupted at any point prior to the first byte of the HTTP payload. Afterwards is always displays a blank page or partial content.

If seems to me that some sort of error should definitely be generated whenever (A) the connection closes before all HTTP headers have been read, and (B) the connection closes before we read the number of bytes we are expecting (ie, a Content-Length header was present). [There are probably more cases/exceptions, but I'm only considering basic HTTP for the moment.] Right now, (A) is broken when the TCP connection closes normally, and (B) is broken no matter how the TCP connection is closed.

Comment 19

[John A.]

I say just change the default value for browser.xul.error_pages.enabled to "false", at least in Seamonkey, and be done with it. Works fine for me.

Actually, I really don't see the comparitive advantage to having error messages replace the page contents in any case, so I'd just chalk it up as a failed experiment and put this bit of code up as a candidate for codebase reduction.

Comment 20

[Dennis Curran]

I get a Connection Interrupted dialogue box on the page every time I try to access  https://ibridge.partners.org/cgi-bin/getAccess/applist.gas.bat I can access the page OK using IE, but since I switched to FF2.0 this happens. FF 1.5 worked fine. It's the only page thus far I'm having trouble with. It is supposed to be a login page requiring my password. Thanks

Comment 21

[Cees T.]

Dissing content is worse than dissing focus. An information bar that doesn't get in the way would solve both problems. IE7 has one.

Comment 23

[Mikko Rantalainen]

I'd guess that this error can be reproduced with large Content-Length header and simply closing the connection before emitting enough bytes. At least Apache seems to try to prevent this type of errors by rewriting Content-Length header to be correct when used with e.g. PHP script.