Closed Bug 280131 Opened 21 years ago Closed 20 years ago

onLoad & onUnload

Categories

(Core :: DOM: Events, defect)

1.0 Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: patrick, Unassigned)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.7.5) Gecko/20041108 Firefox/1.0 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.7.5) Gecko/20041108 Firefox/1.0 While activating "reload" button (at least) the load request is sent before the unload. Reproducible: Always Steps to Reproduce: 1.Load a page (with onUnload attributs set in body tag, making a http request) 2.Unload the page 3.Trapping the events on server side : loading (of the same page) is requested before the unload event request to be done. Actual Results: Nothing but it looks like openning two time a file! Expected Results: Unload should be executed on - window refresh ("reload" button) - move in history (left or right arrow) - closing the window (for the currently diplayed page, of course) NB: Very sorry, but IE 6.0 does so. Konqueror does'nt execute the unload most of the time.
Assignee: general → events
Component: Bugzilla-General → DOM: Events
Product: Bugzilla → Core
QA Contact: default-qa → ian
Version: unspecified → 1.0 Branch
Sounds like content viewer silliness.... Where do we fire onunload from?
So... is this about the fact that we make the request to the _server_ before firing unload? If so, that makes a lot of sense to me -- depending on the server response we may not even try to unload the page.
Patrick writes: ---------------------------------------------- > So... is this about the fact that we make the request to the _server_ > before firing unload? -----> Right. > If so, that makes a lot of sense to me -- depending on the > server response we may not even try to unload the page. -----> I understand the "go as fast as possible" priority. Can you consider the point of view of the programmer on the server side, please ? ---------------------------------------------- Patrick, there is nothing "go as fast as possible" going on here, and we _are_ thinking from a web developer's perspective.. There is a simple matter of correctness. "unload" should be fired when the page is being unloaded. Consider a web page. The user clicks a link and a new load starts. Then one of the following happens: 1) The user presses the Stop button. 2) The site returns and HTTP 204 or 205 response. 3) The site returns data of a type we can't handle (say PDF and the user doesn't have a PDF plugin) and pass off to a helper application instead. In all these cases, the page is NOT unloaded. So firing "unload" in these cases would be wrong. Thus firing of "unload" can't happen until after the response has been received from the server (because we don't know until then whether we might be in case 2 or case 3). It certainly can't happen when the link is clicked (because of all three cases above). So based on your clarification, it looks like this is invalid.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
For the cases 1) and 2), could'nt it be possible to consider that whatever the page diplayed, error page or not, completly or not, the previous page unloading fired an unload event and the new starting page fires a load event. For case 2) nothing would appen after the user has stoped, but the following user action will fire an unload event (circonstances 1., 2. and 3.). I have no idea the right way to handle case 3). It sounds good to me that if the content of a page is CHANGED (for client side reasons 1., 2., 3. or others), then unload event to be fired before the display to be updated or the requested link to be followed. (No idea about faisability!) I remember that I got two consecutive close events with MSIE, when I tryed it. unfortunatly, I dont remember in which circonstances, sorry. But two consecutive close events is not a drama, is it ?
Please look up the 204 and 205 HTTP responses. They explicitly do NOT load a new page or an error page. They exist to either do nothing or to affect the existing page. When they are received, the existing page is most definitely NOT unloaded. > then unload event to be fired before the display to be updated That's what we do. > or the requested link to be followed Define "followed"? > But two consecutive close events is not a drama, is it ? Firing two unload events would break a number of pages that use unload -- unload event handlers are very rarely idempotent.
No, I will not look up the 204 and 205 HTTP responses. I just espected the Mozilla team to look at this problem because I like my sofware or harware users to help me fixing bugs. I dont want to discuss on this problem because I have not enougth knowledges and english is not my mother language. I just noted that MSIE worked better from my point of view on these specific load unload events.
The Mozilla team did look at the problem, and the behavior we have is the only one that can make sense given the constraints imposed on loads...
Hello all, You've done a nice job these 5 last years. It's nearly finished! Testing HTML code: Page 1 (named "Bug_280131.html"): <html> <head> <title>[Bug 280131] </title> </head> An alert message, saying "Page loaded.", should appear when this page is finished loaded.<br /> An alert should apprear when the page is unloaded, that is, if the content is changed because of:<br /> - A link followed (click <a href='Bug_280131_bis.html'><b> here </b></a> to test, (even if this generate a server error), or by moving in the history,<br /> - The tab displaying this page is closed,<br /> - The browser's window (containing this tab, of course) is closed<b style='color:red'>*</b> (before FF ask "Voulez-vous que Firefox enregistre vos onglets pour le prochain démarrage ?". This is the FF bug to be fixed!)...<br /><br /> NB-1: Tested with Firebug activated (but not "open").<br /> <b style='color:red'>*</b> NB-2: The bugs reference (IE6) displays the alert while the browser's window is closed.<br /><br /> Clic <a href='javascript:alert("Page loaded.")'><b> here </b></a> to test the "onLoad" alert dialog,<br /> Clic <a href='javascript:alert("Unload called, nice!")'><b> here </b></a> to test the "onUnload" alert dialog. <body lang='fr-FR' onload='alert("Page loaded.")' onunload='alert("Unload called, nice!")'> </body> </html> Tesing page 2 (named "Bug_280131_bis.html"): <html> <head> <title>[Bug 280131] </title> </head> No alert dialog for this page.<br /> By clicking <a href='Bug_280131.html'><b> here </b></a>, the first page will be displayed again, but without referencing the history. <body lang='fr-FR'> </body> </html> Thanks for the nice job you've done, and keep your chin up Patrick
You need to log in before you can comment on or make changes to this bug.