On Wed, Feb 19, 2014 at 03:39:12PM -0500, Karl Dahlke wrote: > Maybe ... in javaSessionFail just print and set a flag, > Then return because of the error condition. > The calling function might then return because of the error, > and so on, unwinding the stack all the way back to html. > So there was an error but cw->jss is still there.
Sounds like a plan. > in the SwitchCompartment macro, > if js is dead then return, as we do today, > but if it is still there and the abort flag is set then destroy context and > set jss = null and return. Hmm, I wonder if we have any nested SWITCH_COMPARTMENT calls which'd break this. I quite like Chris's idea of leaving the destruction of the context until we're sure the stack has unwound correctly. > > Everything would unwind and free properly, > and the js context would go away, perhaps on the next call. > Maybe that would keep things from becoming a mess. Hopefully. I'm going to implement this tonight to see how it turns out. Would it be possible for the memory-hogging program to be added to jsrt as a button (as you previously mentioned) as that should give a repeatable test for this. The existing way of browsing it then something else which uses javascript triggers the unable to create window object error rather than a javascript session failure. Cheers, Adam. _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
