Closed
Bug 280131
Opened 21 years ago
Closed 20 years ago
onLoad & onUnload
Categories
(Core :: DOM: Events, defect)
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.
Updated•21 years ago
|
Assignee: general → events
Component: Bugzilla-General → DOM: Events
Product: Bugzilla → Core
QA Contact: default-qa → ian
Version: unspecified → 1.0 Branch
Comment 1•21 years ago
|
||
Sounds like content viewer silliness.... Where do we fire onunload from?
Comment 2•20 years ago
|
||
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.
Comment 3•20 years ago
|
||
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
| Reporter | ||
Comment 4•20 years ago
|
||
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 ?
Comment 5•20 years ago
|
||
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.
| Reporter | ||
Comment 6•20 years ago
|
||
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.
Comment 7•20 years ago
|
||
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...
| Reporter | ||
Comment 8•15 years ago
|
||
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.
Description
•