<br><br><div class="gmail_quote">On Wed, Sep 16, 2009 at 10:33 PM, Darin Fisher <span dir="ltr">&lt;<a href="mailto:darin@chromium.org">darin@chromium.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="im">On Wed, Sep 16, 2009 at 9:59 PM, Maciej Stachowiak <span dir="ltr">&lt;<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style="word-wrap:break-word"><br><div><div><div>On Sep 16, 2009, at 4:49 PM, Darin Fisher wrote:</div><br><blockquote type="cite"><br><br><div class="gmail_quote">On Wed, Sep 16, 2009 at 2:21 PM, Maciej Stachowiak <span dir="ltr">&lt;<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div style="word-wrap:break-word"><br><div><div><div>On Sep 16, 2009, at 1:58 PM, John Abd-El-Malek wrote:</div></div>

<div><br><blockquote type="cite"><div class="gmail_quote"> <div><br></div><div>Either way though, I don&#39;t think it&#39;ll work in this case.  I&#39;ve seen pages have 8 beforeunload/unload handlers each sleeping for 200ms, just so that they don&#39;t have 1 handler that&#39;ll trip the slow script detection.  If we decrease the timeout for unload handlers, they would just increase the number of registered handlers proportionally.</div>

 </div></blockquote><div><br></div></div></div><div>I think that setting an upper bound on the amount of time that can be spent in all unload handlers is a better solution than hacking the behavior of the Date API. Because (a) It&#39;s less likely to have unexpected side effects; and (b) there&#39;s no way for content authors to work around it, so we are less likely to end up in an &quot;arms race&quot; situation. There were worries expressed that swapping or context switching might trigger false positives, but I expect this is unlikely in practice, based on our experience with the slow script dialog.</div>

 </div></blockquote><div><br></div><div><br></div><div>I too would like to avoid an arms race, but...</div><div><br></div><div>I disagree.  You&#39;ll get false positives at an unacceptable rate, especially if you try to tamp down the interval to a small fraction of a second.  We saw these problems in spades with Chrome&#39;s hang monitor (detecting unresponsive subprocesses), and we had to push the interval to something larger than we would have liked.</div>

</div></blockquote><div><br></div></div><div>Interesting - I don&#39;t recall every seeing false positives with Safari&#39;s &quot;slow script&quot; detection. Maybe due to our particular timeout design (see below).</div>

<div><br><blockquote type="cite"><div class="gmail_quote"> <div><br></div><div>Counting work instead of time is much more robust.  The getTime call counts is a measure of work, albeit approximate.</div></div></blockquote>

<div><br></div></div><div>The way JavaScriptCore execution time limit works is that the clock doesn&#39;t start ticking until JS execution begins. So it&#39;s unlikely that a full timeout cycle will occur while the process is swapped out or paused, since the clock won&#39;t start running until the process is actually executing JS. And the actual timeout check is only done occasionally (every N loop back edges or function calls, for some value of N). So even if there&#39;s a context switch in the middle of JS execution, it&#39;s unlikely that JS processing will be terminated immediately upon return. So maybe a different solution is appropriate for JavaScriptCore than V8.</div>

<div><br></div></div></div></blockquote><div><br></div></div><div>Consider what happens if during JS execution garbage collection runs.  That could cause portions of the VM to be swapped into RAM, which could cause significant wall clock delay.  Do you discount time spent in GC?</div>
<div class="im">
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div class="gmail_quote">

<div><br></div><div>Also, it is very important to note that content authors are not entirely in control here.  A content author may have some ads on their page, and it may be the ad that is delivering the bad unload handler.  If we applied a limit to all unload handlers, then we&#39;d be punishing both the content author as well as the ad provider.  That doesn&#39;t seem fair to the content author, who might have a legit unload handler.</div>

 </div></blockquote></div></div><br><div>As long as the author installs their unload handlers before the ad does, they won&#39;t have a problem.</div></div></blockquote><div><br></div></div><div>Good point.</div><div class="im">
<div><br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>To help us decide whether (and how) to tackle this for non-V8 ports of WebKit, can the Chrome team share the data they have on the following:</div>

<div><br></div><div>(1) Frequency of pages doing a busy loop in an unload handler. I&#39;ve heard it&#39;s common but no specific data.</div><div>(2) A few examples of URLs to pages that do this, so we can study what they are doing and why.</div>

<div>(3) Frequency of a date-based loop being used to implement the busy loop.</div><div>(4) Average additional delay imposed by unload busy loops.</div><div>(5) Proportion of sites that use busy looping in unload solely for link tracking and not for any other purpose. </div>

<div><br></div></div></blockquote><div><br></div></div><div>You can find links to example sites in the Chromium bug report:</div><div><a href="http://code.google.com/p/chromium/issues/detail?id=7823" target="_blank">http://code.google.com/p/chromium/issues/detail?id=7823</a></div>

<div><br></div><div>The bug contains some distilled data.</div><div><br></div><div>By the way, the issue is not with trouble sites but with trouble ad networks and/or producers.  I believe the web sites are just victims here.</div>
<div class="im">
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>The reason I&#39;m interested in (1)-(4) is to determine if doing nothing is really worse than doing something hackish, as suggested by Adam.</div>

<div><br></div><div>The reason I&#39;m interested in (5) is to determine if &lt;a ping&gt; is an adequate replacement. I think if we break existing techniques, we need to give authors a replacement. unload fires when the user leaves the page in any way whatsoever, including closing the window or typing in the location field. So sites could use I/O in unload plus a busy loop to track the amount of time the user spent on the page, or to save state. If sites are doing that, then &lt;a ping&gt; won&#39;t be an adequate replacement, so we&#39;ll have to do something like Adam&#39;s suggestion to guarantee completion of I/O that is initiated in the unload handler. The reason I think it&#39;s possible sites care about more than just link tracking is that if that&#39;s all they care about, they could just use redirect links, and get a better user experience today than busy looping in unload. If sites are not using redirects for link tracking today, why would they use &lt;a ping&gt; in the future?</div>

<div><br></div></div></blockquote><div><br></div></div><div>The reason why I don&#39;t think they are using it for critical data is because they have a timeout.  If they were trying to persist critical data then they would just use a synchronous XHR.  In this case, they are trying to increase the probability of successfully sending a ping by giving themselves a few 100 ms.</div>

<div><br></div><font color="#888888"><div>-Darin</div></font></div>
</blockquote></div><br><div><br></div><div>By the way, to be clear these ads aren&#39;t on the critical path for link clicks.  A navigation occurs, and the ad just observes unload.  During unload it presumably tries to send home some data (ad impression time, perhaps?).  I&#39;m not sure how a redirect could be used to report such information.</div>
<div><br></div><div>&lt;a ping&gt; is a useful tool nonetheless because you could dynamically create one, and dispatch a click event to it.</div><div><br></div><div>-Darin</div>