Closed
Bug 32469
Opened 25 years ago
Closed 25 years ago
history to work well with cache.
Categories
(Core :: DOM: Navigation, defect, P3)
Core
DOM: Navigation
Tracking
()
M17
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.
Comment 1•25 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
i guess the summary ought to be changed to "back/forward method functionality is
clunky" - works both ways - or rather...doesn't quite work ;)
Assignee | ||
Comment 3•25 years ago
|
||
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.
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•25 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
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•25 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•25 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???
Reporter | ||
Comment 12•25 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•25 years ago
|
||
The reload oddity (behaving like a "*back* to current page" instead of reload)
is bug 35163.
Assignee | ||
Comment 14•25 years ago
|
||
*** This bug has been marked as a duplicate of 21137 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
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.
Description
•