Closed
Bug 202638
Opened 21 years ago
Closed 20 years ago
Offline: no error/notification when interupting page load
Categories
(Core :: Networking: HTTP, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.8alpha3
People
(Reporter: Biesinger, Assigned: Biesinger)
References
Details
Attachments
(1 file)
960 bytes,
patch
|
darin.moz
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•21 years ago
|
||
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
Comment 4•21 years ago
|
||
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
Comment 5•20 years ago
|
||
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
Assignee | ||
Comment 6•20 years ago
|
||
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
Assignee | ||
Updated•20 years ago
|
Attachment #152870 -
Flags: review?(darin)
Assignee | ||
Updated•20 years ago
|
Keywords: helpwanted
Target Milestone: Future → mozilla1.8beta
Comment 7•20 years ago
|
||
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+
Assignee | ||
Updated•20 years ago
|
Attachment #152870 -
Flags: superreview?(bzbarsky)
Comment 8•20 years ago
|
||
Comment on attachment 152870 [details] [diff] [review] maybe this? sr=bzbarsky
Attachment #152870 -
Flags: superreview?(bzbarsky) → superreview+
Assignee | ||
Comment 9•20 years ago
|
||
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
Assignee | ||
Updated•20 years ago
|
Target Milestone: mozilla1.8beta → mozilla1.8alpha3
You need to log in
before you can comment on or make changes to this bug.
Description
•