[Wtr-general] BUG: New IE windows share session state with existingopen windows

[Michael Bolton]

>I see three ways this could happen, there may be more: (1) The variable
"global_foo" is truly "global" on that server from the moment it is
instantiated, and remains in memory even when there is no "running code".
This is contrary to the way I understood globals to function . . . in which
case there was a misunderstanding regarding scope, which in turn is due to
lack of adequate documentation. That is to say, it was my understanding that
controllers constitute "top level" code, and therefore when a controller
exits, all information that is "global" to that controller should be lost.
If, however, a "global" functions across controllers, effecting the whole
"app", then this makes sense . . . but should be better documented. (2) The
variable "global_foo" is supposed to be global only up to the controller
context, but something went wrong and it is getting improperly preserved.
(3) The POST variables are being improperly preserved (cached) between
sessions.

>In order of decreasing liklihood, I would rank these (1), (3), (2). When I
stated that this could be due to some kind of server caching, I was
referring to situation (3) . . . POST variables being improperly cached.
That could be tested but I do not think it is very likely.

It's always remarkable to me that the people are quickest to suspect that
there's a bug in the language--not a bug in their test code, and not a bug
in the application under test.
 
Do you think it's more likely that Ruby preserves the value of variables
across runs, even when memory is deallocated?  Remember that the operating
system would have to collaborate by preserving the contents of whatever
address the global points to.
 
---Michael B.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-general/attachments/20060607/9510001b/attachment.html