Bug 19922 – image doesn't get fetched when requested from an onunload handler.

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Jorge]

An image is requested from the onunload handler, but the img request never gets to the (src=) server. Onunload img loading behaviour is different depending on wether the page gets closed, you're navigating away, or the onunload handler gets called as a function (). The same code that fails in Safari, works fine in FF and Opera, etc. The idea is to track when a user leaves a page. Looks like if the same thing happens when the request if for a <script> instead of an <img>. See the complete description of the problem in comp.lang.javascript thread "unload event more restrictive now on Safari 3.1". Thanks, Jorge.

[Stevo]

Created attachment 22123 [details]
Simple test page showing the unload restrictive behavior

This simple test page shows that if you call a function from a form button, then that function is allowed to make http requests for an image into a Javascript image object. That same function when called from an unload handler (or a beforeunload handler) are apparently being blocked from doing that. Adding an alert into the unload function shows that the unload event is calling the function, it's just being prevented from making the http requests it wants to.

[Stevo]

It seems like the actions of an unload/beforeunload handler have been "sandboxed" to prevent any http requests. This breaks a lot of web pages that wish to track how long a page was active and what actions were taken on it.

This behavior is allowed on all versions of IE, Firefox, Netscape, Mozilla, Opera, and all versions of Safari up to 3.0.4. It's only the launch of Safari 3.1 where this behavior became broken (or deliberately restricted).

In addition to hoping this bug gets fixed, there are a number of us web developers that need a workaround if one is possible. Having it fixed in a nightly build doesn't help us between now and the time of the next Safari release.

[krg]

Plus I have been trying to send along a query string formatted in javascript and sent using a XHR POST request to the server and that doesn't get sent either. So in summary, any http requests are not completing in any unload event handler.

[Alexey Proskuryakov]

(In reply to comment #2)
> It seems like the actions of an unload/beforeunload handler have been
> "sandboxed" to prevent any http requests.

Could you please file a separate bug for onbeforeunoad?

[Jorge]

(In reply to comment #3)
> Plus I have been trying to send along a query string formatted in javascript
> and sent using a XHR POST request to the server and that doesn't get sent
> either. So in summary, any http requests are not completing in any unload event
> handler.

Did you make it a synchronous XHR ?
The (GET, synchronous) XHR in the example URL seems to work : see : http://homepage.mac.com/jorgechamorro/cljs/002/

[krg]

(In reply to comment #5)
> (In reply to comment #3)
> > Plus I have been trying to send along a query string formatted in javascript
> > and sent using a XHR POST request to the server and that doesn't get sent
> > either. So in summary, any http requests are not completing in any unload event
> > handler.
> 
> Did you make it a synchronous XHR ?
> The (GET, synchronous) XHR in the example URL seems to work : see :
> http://homepage.mac.com/jorgechamorro/cljs/002/
> 

This example does indeed work. But is a sync call ok when someone is trying to navigate away from a page?? Although for the purpose i am using[recording time spent on a page, by sending the time spent to the server, when a user exits a page], i won't send any response to the browser, does that affect any client thread/process waiting for any response, in any version??
So far the example provided by Jorge has worked really well, even for 'onbeforeunload'.

[Stevo]

(In reply to comment #5)
> Did you make it a synchronous XHR ?
> The (GET, synchronous) XHR in the example URL seems to work : see :
> http://homepage.mac.com/jorgechamorro/cljs/002/

Thanks for that workaround Jorge. It may end up being all we can do, but for now, I'm going to wait to see how this bug is handled. The webkit team might say "yes indeed we did actively stop unload handlers from making image requests", in which case we're probably forced to use that workaround, unless they block that too. Or they might just say it's a bug that will be fixed in Safari 3.2 which is due in X number of weeks. If this is the case, then I'll be happy enough to not worry about it.

[Stevo]

Any chance of changing the priority? Bugzilla won't let me because I'm not the owner or reporter. Maybe it'll force someone to take a look. There are a bunch of us that really need this fixing before the next release of Safari.

[Alexey Proskuryakov]

As mentioned above, please file a separate bug for onbeforeunload.

[Stevo]

(In reply to comment #9)
> As mentioned above, please file a separate bug for onbeforeunload.

That won't help anything, it'll just be marked as a duplicate.

[Stevo]

(In reply to comment #10)
> (In reply to comment #9)
> > As mentioned above, please file a separate bug for onbeforeunload.
> That won't help anything, it'll just be marked as a duplicate.

Really useful logging bugs here I see.

[T Flynn]

I have also been trying to figure this out for the past 3 days. Finally found this bug report.

The desired behavior is not all that uncommon.  Oftentimes developers want to know how long a visitor was on the page.  Without being able to create an image or use AJAX, there really isn't much else.

I am happy to have found Jorge's workaround.  Is there any word on this issue?  I would prefer not to use a workaround.  What is the purpose of this restriction?

[T Flynn]

The behavior is also occurring in Google Chrome since it is also using WebKit.

[Sergii]

Just want to send small ping (Ajax request) to statistic service when user leave my page.

[Burcu Dogan]

This is absolutely a high priority bug since metric capturing code should invoke the bound function whenever user is navigating out of the page.

[ajay]

Just desperate to get a solution for this issue. Here is a workaround I came up with. Like to share with you all.
It works cross site for browser Safari, Chrome, IE, & firefox. Should work with other browser too.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<script type="text/javascript"> 
function imageget() {
	im = new Image()
	im.src="http://example.com/foo.gif";
	setTimeout('document.myform.submit()', 100);
};
</script>
</head>

<body>
<form name="myform">
<input class="submit" id="but1" type="submit" value="Click Me" onclick="imageget();return false;" />
</form>
</body>

here i am tricking safari by breaking the current call stack by returning false and making a  asynchronous call for the submit using setTimeout. 
Thanks
Ajay

[Alexey Proskuryakov]

Fixed in bug 30457?

[Nate Chapin]

(In reply to comment #17)
> Fixed in bug 30457?

Yes, 30457 should have resolved this. (http://trac.webkit.org/changeset/65910)

[Rob O'Brien]

This doesn't seem to be resolved (tested in 533.19.4). The "Simple test page" attachment displays the same behavior as originally described. Can this be reviewed?

[Nate Chapin]

(In reply to comment #19)
> This doesn't seem to be resolved (tested in 533.19.4). The "Simple test page" attachment displays the same behavior as originally described. Can this be reviewed?

How are you testing it?  Using the Chrome dev channel (WebKit r78450 I believe), I see the request being sent to the network, so I'm interested to know what we're doing differently :)

[Nate Chapin]

(In reply to comment #20)
> (In reply to comment #19)
> > This doesn't seem to be resolved (tested in 533.19.4). The "Simple test page" attachment displays the same behavior as originally described. Can this be reviewed?
> 
> How are you testing it?  Using the Chrome dev channel (WebKit r78450 I believe), I see the request being sent to the network, so I'm interested to know what we're doing differently :)

Wait, never mind.  I just checked the Safari branches in http://trac.webkit.org/browser/branches, and it looks like the relevant patch didn't get picked up until 534.x builds.  This isn't expected to work in 533.19.4.

Sorry for not checking the version numbers before posting.

[Rob O'Brien]

(In reply to comment #21)

This makes sense. I just tested Chrome/534 and it works as expected. I appreciate the quick response.