32469 - history to work well with cache.

Status: VERIFIED DUPLICATE of bug 21137

(Core :: DOM: Navigation, defect, P3)

Description

[R.K.Aa.]

i have these options selected in prefs:
disk cache 5000 KB
memory cache 3000 KB
compare document in cache to document on network: Once per session

However: Whenever i use the back button, Mozilla insists on first resolving the
hostname, then it connects to the host - and *then* first, it re-renders the
page i was on only seconds earlyer.

This makes it slow. But worse yet - if i get disconnected (ppp) i simply get an
error message when hitting "back":
Unable to connect to network. And the previous page won't load even if it's cached.

This does not happen in Netscape 4.7.

Expected functionality:
Mozilla should simply re-render the previous page if it's cached, and place that
URL in the URL field. It doesn't need to resolve hosts or connect to the net for
that.

Comment 1

[joki (gone)]

This is actually a problem with the 'back' method functionality, not the 
actual clicking on the button which is the events part.  Taking a guess at 
history as the most likely place for this.

Comment 2

[R.K.Aa.]

i guess the summary ought to be changed to "back/forward method functionality is
clunky" - works both ways - or rather...doesn't quite work ;)

Comment 3

[Radha on family leave (not reading bugmail)]

Re-summarising

Comment 4

[R.K.Aa.]

the new summary makes it relevant to add a related issue: With the settings

described above: When right-clicking and selecting "Save Page As..." the whole

page is once more downloaded from the net before written to disk. Slow. It

should save the cached page, suggesting the filename in the URL-field as file to

save to. Even without deliberate caching set in preferences, the *current* page

should be cached regardless, so a "save" will save whatever is there.

Comment 5

[Claudius Gayle]

*** Bug 33060 has been marked as a duplicate of this bug. ***

Comment 6

[R.K.Aa.]

Reporter of duplicate bug 33060 set severity to major. I agree with that. These
functions insist on an existing connection to the net, or else they fail:
"back" - "forward" - "view page source" and "save page as..."
This slows Mozilla for all, wastes bandwidth and in addition cripples
functionality majorly for users not connected 24/7. Most users are on modems or
ISDN. I suggest upping severity..

Comment 7

[Claudius Gayle]

I agree. If you're not connected to a LAN it's like running without a cache at all so it's a a double-whammy.

Comment 8

[R.K.Aa.]

Judging from reporter's and CC adresses in bug 33269 it seems upping priority is

also in order. I suggested 33269 was a duplicate of this one. If i'm wrong, at

least work on them should be synchronized to avoid double efforts.

Comment 9

[Scott Furman]

This sounds like a DUP of 21137, which I reported in December.  If you set the
correct load flags in the call to the netlib when hitting the back/forward
buttons, the cache won't contact the origin server to validate the page (unless 
the page is not in the cache).

Comment 10

[Claudius Gayle]

I'm reevaluating this bug in light of the recent Webshell changes. It seems that the bug still exists, it doesn't look like SH makes 
much use of the cache at all as of the 2000042109 builds. This could be nightmarish for anyone on dialup. nominating for 
nsbeta2.

I get the feeling that sometihng has changed between the 4/21 and 4/25 builds but I'm not sure???

Comment 11

[leger]

Putting on [nsbeta2+] radar.  

Comment 12

[R.K.Aa.]

Something's odd for sure. A couple of observations from build ID 2000-042609:

1:
Use of back/forwd. buttons is much quicker than it used to be: It seems
back/forward now do use disk-cache if enabled, but Moz still insists on making a
DNS lookup before rendering a cached page. If i disconnect i thus get a DNS
lookup error alertbox, and no page renders even if cached.

2:
If i select reload - it doesn't reload but reads from cache instead (after DNS
lookup) I use the counter on my homepage as a test:
http://www.tele2.no/cgi-bin/Count.cgi?df=dark_rkaaindex.dat&dd=B&ft=0

The hit gets registered on the site (parallel checking in NC4.7) but the image
doesn't update in Moz. This is wrong behaviour: The image should update when you
command it to, like a reload.
--

I haven't checked how these things work with prefs for cache turned off. I'll
get back to that.

Comment 13

[R.K.Aa.]

The reload oddity (behaving like a "*back* to current page" instead of reload)
is bug 35163.

Comment 14

[Radha on family leave (not reading bugmail)]

*** This bug has been marked as a duplicate of 21137 ***

Comment 15

[Claudius Gayle]

VERIFIED Dupe