Wt

Hi Koen,

YES i am 100% sure the very same setup worked with wt dated 24/09/2010. I have just retried again and the destructor is always called with previous wt but never with wt 3.1.6

I am running a 64-bit non multithreaded build of wt with a httpd connector

This is with Firefox 3.6.10

Regards

Christophe

FYI, i have just tried with the latest git and the problem is still there

Also note that when i kill the browser window, the following message is printed twice in the console :

Asio error: 4121: An established connection was aborted by the software in your host machine

Koen,

Do you want me to set a breakpoint somewhere in debug to see what is going on when i kill the firefox window ?

Hey Christophe,

I went back though older version of Wt to see if I ever got this working using Firefox but could not manage so far. Can you trigger the correct behaviour using Firefox with standard examples of Wt? If so, are you using a special wt_config.xml and how does your setup look like: same computer for client/server, and what browser and OS ?

I believe that the unreliability of detecting a browser closing is a race condition between the browser closing and the asynchronous request to notify the server being sent, and there is alot that could influence that I would suspect.

Regards,

koen

P.S. i am using a httpd connector

Koen,

I have found the setting that cause the problem :

false

if set to true, then the destructor is called.

Is that normal ?

Note that i do not reload the session. I just kill the browser tab.

Regards

Christophe

Hey Christophe,

I was starting to think there was other magic involved since I could not reproduce your problem.

Because a browser refresh cannot be distinguished (easily) from a window closing, we ignored the unload event when we support session refreshes. Perhaps this could be fixed by adding a heuristic where a Wt-unload is ignored right after the session is refreshed --- and still that depends on an ordering of events in the browser that I have not found to be documented (i.e. that the request for the new page precedes the unload event of the previous page). So that will require a bit of experimentation to determine whether it is actually possible.

Regards,

koen

ok thanks for the explanation

i can live with this setting set to true.

You can close the bug

regards

christophe