bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

"Show only this Frame" menu command should use cache

RESOLVED EXPIRED

Status

SeaMonkey
UI Design
RESOLVED EXPIRED
17 years ago
3 years ago

People

(Reporter: Jeremy M. Dolan, Assigned: jag (Peter Annema))

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

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

17 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

17 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"]
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

17 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

17 years ago
-> moz 1.0
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.0
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

17 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

Updated

17 years ago
Depends on: 103944

Comment 7

17 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

Updated

17 years ago
No longer depends on: 103944

Comment 8

17 years ago
moving to mozilla0.9.9
Target Milestone: mozilla1.0 → mozilla0.9.9

Comment 9

17 years ago
Pushing to mozilla1.0.1
Target Milestone: mozilla0.9.9 → mozilla1.0.1

Comment 10

17 years ago
-> default assignee
Assignee: pchen → trudelle
Target Milestone: mozilla1.0.1 → ---

Comment 11

17 years ago
->bryner/future
Assignee: trudelle → bryner
Target Milestone: --- → Future

Comment 12

17 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 13

17 years ago
-> me since this has always bothered me.
Assignee: bryner → blaker
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

17 years ago
cc'ing rpotts... see comment #12

Comment 16

15 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

15 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

15 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

15 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

15 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.
Product: Core → Mozilla Application Suite
Assignee: bross2 → jag
QA Contact: bugzilla
Priority: P3 → --
Target Milestone: Future → ---

Comment 21

9 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

9 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

9 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

9 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

9 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

9 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

9 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

8 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
Last Resolved: 8 years ago
Resolution: --- → EXPIRED

Comment 29

3 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.