Closed Bug 202638 Opened 21 years ago Closed 20 years ago

Offline: no error/notification when interupting page load

Categories

(Core :: Networking: HTTP, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.8alpha3

People

(Reporter: Biesinger, Assigned: Biesinger)

References

Details

Attachments

(1 file)

current cvs build, linux

If I click the offline button in Mozilla while a page is currently loading, the
throbber & progressbar still show progress and the statusbar still shows
"Loading page", even though nothing is loading.

I would expect some kind of error message, or at least
throbber/progressbar/statusbar quietly stopping.
note, even if I go online after that, the pageload does not continue. I have to
hit reload. (which would be fine if I had an indication that the load failed)
-> networking, affects ftp as well...
Component: Networking: HTTP → Networking
QA Contact: httpqa → benc
Summary: go offline while page is loading -> mozilla claims page is still loading → Offline: no error/notification when interupting page load
+clean-report
Keywords: clean-report
hmm... this doesn't sound like a networking bug to me.  going offline should
result in network requests failing with NS_ERROR_OFFLINE.  i doubt necko isn't
generating OnStopRequest events.  probably the browser status handler is not
getting the right notifications from the webprogresslistener or something like
that.  maybe someone is expecting NS_BINDING_ABORTED (which corresponds to the
user pressing the STOP button).

-> xp apps
Assignee: darin → jaggernaut
Component: Networking → XP Apps
QA Contact: benc → paw
QA Contact: pawyskoczka → benc
Blocks: 131500
back to http component.  i ran a quick test, and indeed necko is not generating
OnStopRequest events when the user goes offline :-(
Assignee: jag → darin
Component: XP Apps → Networking: HTTP
Keywords: helpwanted
QA Contact: benc → core.networking.http
Target Milestone: --- → Future
Attached patch maybe this?Splinter Review
this'd do it; BUT it generates NS_ERROR_ABORT instead of NS_ERROR_OFFLINE...

however, I do think that this is still a good patch, since the it makes the
code agree with the comments :) and because because sockettransport consumers
should probably know about the fact that the sockettransportservice shut
down...
Assignee: darin → cbiesinger
Status: NEW → ASSIGNED
Keywords: helpwanted
Target Milestone: Future → mozilla1.8beta
Comment on attachment 152870 [details] [diff] [review]
maybe this?

r=darin

This makes sense.  You want to make sure the |else| clause is followed when we
get the unexpected detach from the STS.  I'm not sure why I coded it as an
if-elseif previously, but this looks good to me.
Attachment #152870 - Flags: review?(darin) → review+
Attachment #152870 - Flags: superreview?(bzbarsky)
Comment on attachment 152870 [details] [diff] [review]
maybe this?

sr=bzbarsky
Attachment #152870 - Flags: superreview?(bzbarsky) → superreview+
Checking in base/src/nsSocketTransport2.cpp;
/cvsroot/mozilla/netwerk/base/src/nsSocketTransport2.cpp,v  <-- 
nsSocketTransport2.cpp
new revision: 1.22; previous revision: 1.21
done
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.8beta → mozilla1.8alpha3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: