19922 2008-07-07 00:58:26 -0700 image doesn't get fetched when requested from an onunload handler. 2011-02-22 14:24:34 -0800 1 1 1 Unclassified WebKit New Bugs 312.x All All RESOLVED FIXED http://homepage.mac.com/jorgechamorro/cljs/002/ P1 Major --- 1 jorgechamorro webkit-unassigned ap beidson burcujdogan fishd gkumarrahul info.varghese japhet jorgechamorro rob+webkit sedgar stevo10018 tflynn25 oldest_to_newest 85309 0 jorgechamorro 2008-07-07 00:58:26 -0700 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. 85312 1 22123 stevo10018 2008-07-07 01:54:56 -0700 Created attachment 22123 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. 85313 2 stevo10018 2008-07-07 01:59:00 -0700 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. 85315 3 gkumarrahul 2008-07-07 03:33:36 -0700 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. 85320 4 ap 2008-07-07 04:35:07 -0700 (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? 85346 5 jorgechamorro 2008-07-07 08:51:53 -0700 (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/ 85353 6 gkumarrahul 2008-07-07 10:17:38 -0700 (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'. 85378 7 stevo10018 2008-07-07 12:46:02 -0700 (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. 85780 8 stevo10018 2008-07-11 08:45:57 -0700 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. 85782 9 ap 2008-07-11 09:34:56 -0700 As mentioned above, please file a separate bug for onbeforeunload. 85890 10 stevo10018 2008-07-14 07:41:25 -0700 (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. 97367 11 stevo10018 2008-11-01 05:18:20 -0700 (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. 99510 12 tflynn25 2008-11-20 11:15:49 -0800 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? 99521 13 tflynn25 2008-11-20 11:44:26 -0800 The behavior is also occurring in Google Chrome since it is also using WebKit. 181243 14 sedgar 2010-01-15 08:49:27 -0800 Just want to send small ping (Ajax request) to statistic service when user leave my page. 209780 15 burcujdogan 2010-04-07 12:28:36 -0700 This is absolutely a high priority bug since metric capturing code should invoke the bound function whenever user is navigating out of the page. 212647 16 info.varghese 2010-04-14 16:22:57 -0700 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 286256 17 ap 2010-09-28 08:29:14 -0700 Fixed in bug 30457? 286267 18 japhet 2010-09-28 08:44:28 -0700 (In reply to comment #17) > Fixed in bug 30457? Yes, 30457 should have resolved this. (http://trac.webkit.org/changeset/65910) 355550 19 rob+webkit 2011-02-22 13:19:33 -0800 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? 355554 20 japhet 2011-02-22 13:31:30 -0800 (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 :) 355556 21 japhet 2011-02-22 13:34:48 -0800 (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. 355604 22 rob+webkit 2011-02-22 14:24:34 -0800 (In reply to comment #21) This makes sense. I just tested Chrome/534 and it works as expected. I appreciate the quick response. 22123 2008-07-07 01:54:56 -0700 2008-07-07 01:54:56 -0700 Simple test page showing the unload restrictive behavior unloadtest.html text/plain 707 stevo10018 PGh0bWw+PGJvZHk+DQo8YSBocmVmPSJ1bmxvYWR0ZXN0Lmh0bWwiPmNsaWNrIHRvIG5hdmlnYXRl IGF3YXkgKGFuZCBjYXVzZSB1bmxvYWQgZXZlbnQpPC9hPg0KPHNjcmlwdD4NCnZhciBzdGFydGVk PW5ldyBEYXRlKCkuZ2V0VGltZSgpOw0KdmFyIGltajsNCmZ1bmN0aW9uIG15dW5sb2FkZnVuYygp DQp7DQoJdmFyIGRpZmY9KG5ldyBEYXRlKCkuZ2V0VGltZSgpLXN0YXJ0ZWQpLzEwMDA7DQoJaW1q PW5ldyBJbWFnZSgpOw0KCXZhciB1PSJodHRwOi8vZXhhbXBsZS5jb20vdGltZS5naWY/IitkaWZm Ow0KCWltai5zcmM9dTsNCglkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgib3V0cHV0ZGl2IikuaW5u ZXJIVE1MKz0oInJlcXVlc3RlZCAiK3UrIjxicj4iKTsNCn0NCmlmKHdpbmRvdy5hZGRFdmVudExp c3RlbmVyKQ0KCXdpbmRvdy5hZGRFdmVudExpc3RlbmVyKCd1bmxvYWQnLG15dW5sb2FkZnVuYyxm YWxzZSk7DQplbHNlIGlmKHdpbmRvdy5hdHRhY2hFdmVudCkNCgl3aW5kb3cuYXR0YWNoRXZlbnQo J29udW5sb2FkJyxteXVubG9hZGZ1bmMpOw0KPC9zY3JpcHQ+DQo8Zm9ybT4NCgk8aW5wdXQgdHlw ZT1idXR0b24gdmFsdWU9ImNsaWNrIG1lIHRvIHByb3ZlIG15dW5sb2FkZnVuYyBmdW5jdGlvbiIg b25jbGljaz0ibXl1bmxvYWRmdW5jKCkiPg0KPC9mb3JtPg0KPGRpdiBpZD0ib3V0cHV0ZGl2Ij48 L2Rpdj4NCjwvYm9keT48L2h0bWw+DQo=