Opened 14 years ago

Closed 13 years ago

#4478 closed enhancement (duplicate)

beforeUnload functionality

Reported by: guest Owned by: James Burke
Priority: high Milestone: future
Component: General Version: 0.9
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by dante)

In my application, we have some cases where a user can edit a form. This leads to the situation where if the user accidentally navigates away from the web page before submitting the form, they can lose work.

I want the ability to prompt the user to confirm whether or not they want to navigate away from the page if they have any dirty forms.

I looked at using Dojo's dojo.addOnUnload for this, but there seems to be a couple of problems:

1) dojo.addOnUnload doesn't specify the order in which unload functions are executed, so it's possible for cleanup actions (e.g. the destruction of nodes) to occur before the user vetoes the unload, and

2) there is no mechanism to veto the unload

I'd propose that Dojo add a addBeforeUnload function with which clients can register functions that are executed before any of the onUnload functions execute, and if any of the the beforeUnload functions return false:

1) navigation away from the page is cancelled, and

2) none of the onUnload functions execute

Change History (9)

comment:1 Changed 14 years ago by Adam Peller

onbeforeunload is the right place to do such a thing, but it needs to be separate from onunload events. currently, Dojo seems to take ownership of onbeforeunload to handle onunload events and in other places like rich text.

comment:2 Changed 14 years ago by Adam Peller

Owner: changed from anonymous to James Burke

James, what's your take on this?

comment:3 Changed 14 years ago by James Burke

Milestone: 1.2

I can see where we might be able to pass the beforeunload event to the addOnUnload callbacks. What is not clear yet to me is how we can detect on the event when it has been canceled. It might be possible, I just have to run through the browsers and see what properties are set after the event is canceled. I suppose we should also differentiate between preventDefault() which should stop the unloading of the page, and stopPropagation(), which should prevent other unload callbacks from being fired.

There is no way to guarantee order (first one registered is first one called). Note that Dojo might sneak an unload callback in before your modules execute. In that case, you could go hardcore and unshift onto the dojo._unloaders array to make sure you are first. Not recommended since you are accessing a "private" variable, but it would do if necessary.

Also, to reiterate peller's comment, addOnUnload binds to beforeunload, so I believe we can reuse the dojo.addOnUnload machinery for this, as long as we can reliably detect if the event has been stopped after we notify each addOnUnload callaback. That part needs some investigation.

comment:4 Changed 14 years ago by Adam Peller

I don't think you can tell the unload has been canceled by any state except for the return value of onBeforeUnload, so it seems that we somehow have to assure that anything the user intended to be registered as "onBeforeUnload" fires before anything we might hook there that was really intended to happen "onUnload". This may require more API additions :(

I'm not sure it really makes sense, nor should it usually be necessary, to chain onBeforeUnload events intended to return false, but I suppose it would be nice for completeness.

comment:5 Changed 14 years ago by James Burke

Milestone: 1.22.0

Yeah, I was hoping to not put in special hooks to get user's code in before dojo, although I guess the rest of the functionality is not very useful without it. Maybe something to consider for 2.0 then when we can muck more with the APIs.

comment:6 Changed 14 years ago by Adam Peller

well, I'm not excited about the prospect, but it might just be an addition, e.g. addBeforeOnUnload()

comment:7 Changed 14 years ago by alex

Milestone: 2.01.3

Milestone 2.0 deleted

comment:8 Changed 14 years ago by dante

Description: modified (diff)

+1 on something like this in 1.2 ... if we can do that here ...

see also #6411 ... this would also provide a workaround for #3242 i think.

though dojox.lang.aspect may suffice in some cases for uses?

comment:9 Changed 13 years ago by James Burke

Milestone: 1.3future
Resolution: duplicate
Status: newclosed

Closing this in favor of using #6411 to track this issue.

Note: See TracTickets for help on using tickets.