history to work well with cache.

VERIFIED DUPLICATE of bug 21137

Status

()

Core
Document Navigation
P3
major
VERIFIED DUPLICATE of bug 21137
18 years ago
10 years ago

People

(Reporter: R.K.Aa., Assigned: Radha on family leave (not reading bugmail))

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2+])

(Reporter)

Description

18 years ago
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

18 years ago
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.
Assignee: joki → radha
Component: Event Handling → History
QA Contact: janc → claudius
(Reporter)

Comment 2

18 years ago
i guess the summary ought to be changed to "back/forward method functionality is
clunky" - works both ways - or rather...doesn't quite work ;)
Re-summarising
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: back button functionality is clunky → history to work well with cache.
Target Milestone: --- → M17
(Reporter)

Comment 4

18 years ago
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

18 years ago
*** Bug 33060 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 6

18 years ago
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

18 years ago
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.
Severity: normal → major
(Reporter)

Comment 8

18 years ago
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

18 years ago
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

18 years ago
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???
Keywords: nsbeta2
OS: Linux → All
Hardware: PC → All

Comment 11

18 years ago
Putting on [nsbeta2+] radar.  
Whiteboard: [nsbeta2+]
(Reporter)

Comment 12

18 years ago
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.
(Reporter)

Comment 13

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

*** This bug has been marked as a duplicate of 21137 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 15

18 years ago
VERIFIED Dupe
Status: RESOLVED → VERIFIED

Updated

10 years ago
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.