Faye dies when user leaves page but then chooses to stay on page through JS confirmation.

[Tyler Brown]

I have my users confirm to leave page through some JS:

window.onbeforeunload = page_leave;
function page_leave() {
return "All active chats will be disconnected.";
}

If the user chooses to stay on the page, faye no longer works.
(Messages are no longer sent or received.) Perhaps there is something
in faye.js that kills the connection on the onbeforeunload event? Is
there a way around this?

[Tyler Brown]

I forgot to mention I'm using Chrome on OSX. Happens every time.
Haven't tested other browsers yet.

[James Coglan]

On 8 November 2011 16:50, Tyler Brown <ty...@sociallyu.com> wrote:

Perhaps there is something
in faye.js that kills the connection on the onbeforeunload event? Is
there a way around this?

Faye listens to beforeunload and disconnects itself cleanly. I found that listening for unload often means the disconnect message isn't sent before the page unloads, meaning many more clients are disconnected through timeouts on the server side than through clean disconnect. If there's another event that means disconnect will be sent when the user is really leaving page, and doesn't break your code in this way, I will switch to it.

[Tyler Brown]

That was my suspicion. I understand that beforeunload is more reliable
than unload, but the problem is that the only way to create a page
leave confirmation is through the beforeunload event. Perhaps a page
leave confirmation should be built into faye as an option? Only
display it if there is still an open connection and give us developers
a way to configure the message.

My business logic requires that chat sessions be closed on page leave,
so I'd like to make users confirm the page leave if they have a chat
open.

[James Coglan]

On 8 November 2011 17:19, Tyler Brown <ty...@sociallyu.com> wrote:

Perhaps a page
leave confirmation should be built into faye as an option?

I think a better option, rather than baking UI concerns into Faye, would be to provide a means of disabling it. I'm already considering an API for disabling features of the client, for example switching off the websocket transport. In your case, we could call the feature 'autodisconnect', since this is sufficiently abstract to make sense in non-browser environments, and allow the client to disable it like so:

    client.disable('autodisconnect')

The same API could be used for selectively disabling transports. You could disable autodisconnect and instead make sure you call client.disconnect() yourself in your beforeunload handler if the user leaves the page.

What do you think?

[Tyler Brown]

That sounds fantastic, sir!