Closed
Bug 97554
Opened 23 years ago
Closed 14 years ago
"Show only this Frame" menu command should use cache
Categories
(SeaMonkey :: UI Design, defect)
Tracking
(Not tracked)
RESOLVED
EXPIRED
People
(Reporter: jmd, Assigned: jag+mozilla)
References
()
Details
When I click show only this frame, the frame is reloaded off the network. simply changing the view of data already on screen shouldn't load anything off the network.
Comment 1•23 years ago
|
||
yup... looks like we are inproperly interpreting 'cache-control: no-cache="Set-Cookie"' -> me
Assignee: gordon → darin
Component: Networking: Cache → Networking: HTTP
Updated•23 years ago
|
Summary: "Show only this Frame" menu command should use cache → "Show only this Frame" menu command should use cache [Cache-control: no-cache="Set-Cookie"]
Comment 2•23 years ago
|
||
Theres a bug, somewhere (or maybe it was just in a review comment), on http doing strstr rather than proper parsing all over the place. What does no-cache="Set-Cookie" mean, anyway? Besides, show only this frame needs to use the right loadflags? Even if the page does say cache-control: no-cache, we still shouldn't reload.
Comment 3•23 years ago
|
||
agreed.. there really are two problems here. anyways, wrt the no-cache one: RFC 2616, section 14.9.1, says: If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests. If the no-cache directive does specify one or more field-names, then a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, the specified field-name(s) MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.
Comment 4•23 years ago
|
||
-> moz 1.0
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.0
Comment 5•23 years ago
|
||
IMO, this should be identical to a session history load. We really really should split this up, though, and file that on xpapps to set the load flags correctly. (Ideally we'd keep the contents of forms, too. We probably don't)
Comment 6•23 years ago
|
||
agreed.. see bug 103944.
Summary: "Show only this Frame" menu command should use cache [Cache-control: no-cache="Set-Cookie"] → "Show only this Frame" menu command should use cache
Comment 7•23 years ago
|
||
-> XPApps ("Show only this Frame" should do a LOAD_HISTORY)
Assignee: darin → pchen
Status: ASSIGNED → NEW
Component: Networking: HTTP → XP Apps
QA Contact: tever → sairuh
moving to mozilla0.9.9
Target Milestone: mozilla1.0 → mozilla0.9.9
Pushing to mozilla1.0.1
Target Milestone: mozilla0.9.9 → mozilla1.0.1
Comment 10•23 years ago
|
||
-> default assignee
Assignee: pchen → trudelle
Target Milestone: mozilla1.0.1 → ---
Comment 12•23 years ago
|
||
Darin, it seems that nsIWebNavigation's LOAD_FLAGS_NONE corresponds to LOAD_HISTORY, so isn't that what we're already doing...? (I already explicitly called nsIWebNavigation::LoadURI and passing LOAD_FLAGS_NONE but the network was still contacted, on this and seemingly all frame pages).
Comment 14•23 years ago
|
||
nsIWebNavigation doesn't look like it has a LOAD_HISTORY flag. What you really want is nsIRquest::LOAD_FROM_CACHE set on the request. Looking at nsDocShell, it seems to have its own history code, or at least its own API. I don't know how that stuff is meant to work...
Comment 15•23 years ago
|
||
cc'ing rpotts... see comment #12
Comment 16•21 years ago
|
||
No comments since 4/2/2002. I belive fixing this bug is quite important, since it would make mozilla much smoother in this situation.
Comment 17•21 years ago
|
||
Is there a different between loading from cache and loading from memory (aka if the page is in memory/RAM)? If so, then I was gonna suggest loading from memory instead of cache.
Comment 18•21 years ago
|
||
This seems like it would apply to all platforms. It applies to Windows at least. Should we change to: OS -> All Hardware -> All
Reporter | ||
Comment 19•21 years ago
|
||
Kevin, using memory for this would probably be dependant on another bug (one I believe I filed) which states all currently displayed pages should be maintained in memory, regardless of cache settings.
Comment 20•21 years ago
|
||
Have just come across this bug in Firefox 0.8, and looking through the bug report nothing seems to have been done about it for quite a while. I also notice that bug 84106 shows a very similar scenario, only when saving rather than redisplaying and this seems to be getting more attention. Whilst moving frames is maybe not as serious a dataloss issue as saving, it's still something which doesn't work the way the user expects and could easily be handled much better by mozilla. Also - the OS should really be all for this as it's not platform specific.
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Updated•17 years ago
|
Assignee: bross2 → jag
QA Contact: bugzilla
Updated•16 years ago
|
Priority: P3 → --
Target Milestone: Future → ---
Comment 21•15 years ago
|
||
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
Comment 22•15 years ago
|
||
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Comment 23•15 years ago
|
||
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Comment 24•15 years ago
|
||
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Comment 25•15 years ago
|
||
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Comment 26•15 years ago
|
||
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Comment 27•15 years ago
|
||
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Comment 28•14 years ago
|
||
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
Comment 29•9 years ago
|
||
As far as I can tell, this "bug" (if you will...) still exists in FF 42 (Nov 2015). Is it still considered a bug? Is it being fixed? Should this bug report be "opened" again?
You need to log in
before you can comment on or make changes to this bug.
Description
•