97554 - "Show only this Frame" menu command should use cache

Status: RESOLVED EXPIRED

(SeaMonkey :: UI Design, defect)

Description

[Jeremy M. Dolan]

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

[Darin Fisher]

yup... looks like we are inproperly interpreting 'cache-control:
no-cache="Set-Cookie"'

-> me

Comment 2

[Bradley Baetz (:bbaetz)]

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

[Darin Fisher]

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

[Darin Fisher]

-> moz 1.0

Comment 5

[Bradley Baetz (:bbaetz)]

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

[Darin Fisher]

agreed.. see bug 103944.

Comment 7

[Darin Fisher]

-> XPApps ("Show only this Frame" should do a LOAD_HISTORY)

Comment 8

[Paul Chen]

moving to mozilla0.9.9

Comment 9

[Paul Chen]

Pushing to mozilla1.0.1

Comment 10

[Asa Dotzler [:asa]]

-> default assignee

Comment 11

[Peter Trudelle]

->bryner/future

Comment 12

[Blake Ross]

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

[Blake Ross]

-> me since this has always bothered me.

Comment 14

[Bradley Baetz (:bbaetz)]

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

[Darin Fisher]

cc'ing rpotts... see comment #12

Comment 16

[Ido Beeri]

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

[Kevin Ar18]

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

[Kevin Ar18]

This seems like it would apply to all platforms.  It applies to Windows at least.

Should we change to:
OS -> All
Hardware -> All

Comment 19

[Jeremy M. Dolan]

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

[Simon Andrews]

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.

Comment 21

[Robert Kaiser]

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 22

[Robert Kaiser]

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

[Robert Kaiser]

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

[Robert Kaiser]

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

[Robert Kaiser]

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

[Robert Kaiser]

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

[Robert Kaiser]

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

[Robert Kaiser]

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

Comment 29

[yxzivhso]

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?