Conn: Unreachable server should cause cached data to be displayed

RESOLVED WONTFIX

Status

()

Core
Networking
P3
enhancement
RESOLVED WONTFIX
18 years ago
2 years ago

People

(Reporter: Scott Furman, Unassigned)

Tracking

Trunk
Future
All
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
In prior versions of Navigator, the cached version of a page was shown (with a
warning dialog) if the origin server could not be contacted.
(Reporter)

Updated

18 years ago
Blocks: 14050

Comment 1

18 years ago
Mass move of all bugs without target milestones to M13.

Comment 2

18 years ago
Bulk move of all Cache (to be deleted component) bugs to new Networking: Cache
component.

Comment 3

18 years ago
Assigning fur's cache bugs to Gordon. He can split them up with davidm.

Updated

18 years ago
Target Milestone: M13 → M14

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 4

18 years ago
Seems non-essential for beta. Moving to M15.
Target Milestone: M14 → M15

Comment 5

18 years ago
Assigning to ruslan per warren's request.
Assignee: gordon → ruslan
Status: ASSIGNED → NEW
Target Milestone: M15 → M16

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 6

18 years ago
Moving to M17 which is now considered part of beta2.
Target Milestone: M16 → M17

Updated

18 years ago
Keywords: beta2
Whiteboard: 1d

Comment 7

18 years ago
I added some code (not enabled yet) which will return the cached response in 
cases when the connection can't be established with the Success serverity but 
with the original error code. The docshell needs to check for the error code and 
if it's there - pop-up the dialog box complaining about it.
Assignee: ruslan → travis
Status: ASSIGNED → NEW

Comment 8

18 years ago
Um, details on where this error is returned from?

Updated

18 years ago
Keywords: nsbeta2

Comment 9

18 years ago
Putting on [nsbeta2-] radar. Not critical to beta2.  Assigning to valeski 
temporarily.
Assignee: travis → valeski
Keywords: nsbeta3
Whiteboard: 1d → [nsbeta2-]1d

Comment 10

18 years ago
ruslan, is your code in? what code do we look for?
Whiteboard: [nsbeta2-]1d → [nsbeta2-]1d[nsbeta3-]

Comment 11

18 years ago
It's in and it can be enabled, but the docshell needs to display smth. Necko 
will just return cached copy.
Status: NEW → ASSIGNED

Comment 12

18 years ago
ruslan, how do we know when it's cached? check some status code on the channel?

Comment 13

17 years ago
-> gagan until we get a better idea of what to look for.
Assignee: valeski → gagan
Status: ASSIGNED → NEW

Comment 14

17 years ago
Clearing very old milestone (M17) in hope of reevaluation.
Target Milestone: M17 → ---

Comment 15

17 years ago
should be looked at after the new cache lands. 
->neeti
Assignee: gagan → neeti
Target Milestone: --- → mozilla0.9.1

Comment 16

17 years ago
Darin, any suggestions on what to do with this bug?  Do you know anything about 
what Ruslan put in place?

Comment 17

17 years ago
The correct/clean way IMHO is that we should intercept the errors propogated 
from the transport. currently we don't!-- we just let it send the error message 
directly to the progress listener handed in to the channel. So essentially we 
need a progress listener (in the channel) that we can hand over to the socket 
transport. once we get the notification of server not reached, we should turn 
around pop up the alert box and send data from the cache. 

Comment 18

17 years ago
gagan: i agree

Comment 19

17 years ago
...but hasn't HTTP already truncated/doomed the old cache entry?  Maybe not, if 
it was simply trying to validate the entry.  Sounds like this is an HTTP issue, 
more than a cache issue.
Component: Networking: Cache → Networking: HTTP

Comment 20

17 years ago
moving to 0.9.2
Keywords: nsbeta2, nsbeta3 → nsbeta1+
Whiteboard: [nsbeta2-]1d[nsbeta3-]
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 21

17 years ago
*** Bug 75944 has been marked as a duplicate of this bug. ***

Comment 22

17 years ago
qa to me.
Severity: minor → enhancement
QA Contact: tever → benc
Summary: Unreachable server should cause cached data to be displayed → [RFE] Unreachable server should cause cached data to be displayed

Updated

17 years ago
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Updated

17 years ago
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Updated

17 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Comment 23

17 years ago
*** Bug 100917 has been marked as a duplicate of this bug. ***

Comment 24

17 years ago
See also bug 28586, Should use placeholder error page, not dialog, for 
inaccessible pages.

Updated

17 years ago
Keywords: 4xp

Updated

16 years ago
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Updated

16 years ago
Target Milestone: mozilla0.9.6 → mozilla0.9.8

Updated

16 years ago
Target Milestone: mozilla0.9.8 → Future

Comment 25

16 years ago
This would be a nice improvement, and relatively simple to implement. Nominating
for Mozilla 1.0 and nsbeta1.
Keywords: mozilla1.0, nsbeta1

Comment 26

16 years ago
per adt, not critical for nsbeta1. hence minus.
Keywords: nsbeta1 → nsbeta1-

Comment 27

16 years ago
+ conn - working on more detailed offline/online testcases. 
Summary: [RFE] Unreachable server should cause cached data to be displayed → [RFE] Conn: Unreachable server should cause cached data to be displayed

Updated

16 years ago
Component: Networking: HTTP → Networking

Comment 28

15 years ago
moving neeti's futured bugs for triaging.
Assignee: neeti → new-network-bugs

Updated

15 years ago
Summary: [RFE] Conn: Unreachable server should cause cached data to be displayed → Conn: Unreachable server should cause cached data to be displayed
we do some different things in offline mode - which seems like the right plan for now
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.