I’m building a web app where:
-
run time copies of documents are created through a ‘webqueryopen’ agent
-
the run time copies populate an embedded HTML view in a form
-
clicking on the link in the embedded view presents the dialog box to open/save the file attachment on the underlying document (the run time copies are never actually opened themselves)
-
the run time copies are deleted via a LotusScript agent called via JavaScript in the ‘onUnload’ event - the agent uses a key generated in step 1 to identify the documents for deletion (Remote_User~~DocDateAsText).
-
the ‘agent done’ message is suppressed by writing the agent output to a hidden iframe
Everything works fine except in cases where the user clicks the refresh button on the page containing the embedded view.
When the user does this, the WebQueryOpen agent runs BEFORE the agent in the ‘onUnload’ event with the result that the newly created documents get deleted.
Is it the case, then, that when refreshing a page the ‘onUnload’ event of the initial ‘version’ of the page fires after the ‘WebQueryOpen’ output of the subsequent ‘version’ reaches the browser - ie it is the WQO output that forces the unload - rather than the browser first unloading the page then trying to reload it (triggering the WQO in the middle)?
Addendum: the situation I’m describing seems to be in Firefox 3 - not IE7 which seems to fire the ‘onunload’ before running the WQO.
Subject: WebQueryOpen and OnUnload Question
That’s up to the browser – Firefox doesn’t “unload” the current page until it receives the head of the new page or the request times out, IE unloads when the location change request is made. Who’s right? Well, if you cancel the new page request before the new page begins to load, the old page is still active in the browser (you can scroll it, use the links and buttons, play media, etc.), so can you really say that the old page had been unloaded?
Subject: RE: WebQueryOpen and OnUnload Question
Quite interesting really.
Initially I’d have thought the IE way was the most intuitive - well, it was the way I was building the thing but that was actually latterly (my initial approach was to use the ‘onbeforeunlod’ event but that didn’t work in IE) - but I can well see the logic behind the Firefox way now that you highlight it.
I’ve managed to get around the issue by writing separate pieces of code for IE and Firefox - ah, the joys of browser development. I call one javascript function on the ‘unload’ event if it’s IE and call another javascript function on the ‘onbeforeunload’ event if it’s Firefox. The latter uses a javascript variable which is set in the ‘onclick’ of the attachment link and I had some fun trying to reset it in cases where the user clicks the ‘cancel’ button on the File Save/Open dialog (solved by resetting the variable in the ‘onfocus’ event).
Anyway, thanks for the input Stan - I might otherwise have given up or gone round in circles for ages.