Bug 19922 - image doesn't get fetched when requested from an onunload handler.
Summary: image doesn't get fetched when requested from an onunload handler.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 312.x
Hardware: All All
: P1 Major
Assignee: Nobody
URL: http://homepage.mac.com/jorgechamorro...
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-07 00:58 PDT by Jorge
Modified: 2011-02-22 14:24 PST (History)
12 users (show)

See Also:


Attachments
Simple test page showing the unload restrictive behavior (707 bytes, text/plain)
2008-07-07 01:54 PDT, Stevo
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jorge 2008-07-07 00:58:26 PDT
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.
Comment 1 Stevo 2008-07-07 01:54:56 PDT
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.
Comment 2 Stevo 2008-07-07 01:59:00 PDT
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.
Comment 3 krg 2008-07-07 03:33:36 PDT
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.
Comment 4 Alexey Proskuryakov 2008-07-07 04:35:07 PDT
(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?
Comment 5 Jorge 2008-07-07 08:51:53 PDT
(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/
Comment 6 krg 2008-07-07 10:17:38 PDT
(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'.
Comment 7 Stevo 2008-07-07 12:46:02 PDT
(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.
Comment 8 Stevo 2008-07-11 08:45:57 PDT
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.
Comment 9 Alexey Proskuryakov 2008-07-11 09:34:56 PDT
As mentioned above, please file a separate bug for onbeforeunload.
Comment 10 Stevo 2008-07-14 07:41:25 PDT
(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.
Comment 11 Stevo 2008-11-01 05:18:20 PDT
(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.
Comment 12 T Flynn 2008-11-20 11:15:49 PST
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?
Comment 13 T Flynn 2008-11-20 11:44:26 PST
The behavior is also occurring in Google Chrome since it is also using WebKit.
Comment 14 Sergii 2010-01-15 08:49:27 PST
Just want to send small ping (Ajax request) to statistic service when user leave my page.
Comment 15 Burcu Dogan 2010-04-07 12:28:36 PDT
This is absolutely a high priority bug since metric capturing code should invoke the bound function whenever user is navigating out of the page.
Comment 16 ajay 2010-04-14 16:22:57 PDT
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
Comment 17 Alexey Proskuryakov 2010-09-28 08:29:14 PDT
Fixed in bug 30457?
Comment 18 Nate Chapin 2010-09-28 08:44:28 PDT
(In reply to comment #17)
> Fixed in bug 30457?

Yes, 30457 should have resolved this. (http://trac.webkit.org/changeset/65910)
Comment 19 Rob O'Brien 2011-02-22 13:19:33 PST
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?
Comment 20 Nate Chapin 2011-02-22 13:31:30 PST
(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 :)
Comment 21 Nate Chapin 2011-02-22 13:34:48 PST
(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.
Comment 22 Rob O'Brien 2011-02-22 14:24:34 PST
(In reply to comment #21)

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