Closed Bug 32469 Opened 25 years ago Closed 25 years ago

history to work well with cache.

Categories

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

defect

Tracking

()

VERIFIED DUPLICATE of bug 21137

People

(Reporter: spam, Assigned: radha)

References

Details

(Whiteboard: [nsbeta2+])

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.
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
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
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.
*** Bug 33060 has been marked as a duplicate of this bug. ***
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..
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
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.
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).
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
Putting on [nsbeta2+] radar.
Whiteboard: [nsbeta2+]
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.
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
Closed: 25 years ago
Resolution: --- → DUPLICATE
VERIFIED Dupe
Status: RESOLVED → VERIFIED
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.