<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.webkit.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>52264</bug_id>
          
          <creation_ts>2011-01-11 17:23:04 -0800</creation_ts>
          <short_desc>REGRESSION (r71562): servePendingRequests() no longer called when resources are done loading.</short_desc>
          <delta_ts>2011-01-11 17:57:58 -0800</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>New Bugs</component>
          <version>528+ (Nightly build)</version>
          <rep_platform>Other</rep_platform>
          <op_sys>OS X 10.5</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords>InRadar, Regression</keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          <dependson>27165</dependson>
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Andy Estes">aestes</reporter>
          <assigned_to name="Andy Estes">aestes</assigned_to>
          
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>332816</commentid>
    <comment_count>0</comment_count>
    <who name="Andy Estes">aestes</who>
    <bug_when>2011-01-11 17:23:04 -0800</bug_when>
    <thetext>REGRESSION (r71562): servePendingRequests() no longer called when resources are done loading.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>332822</commentid>
    <comment_count>1</comment_count>
    <who name="Andy Estes">aestes</who>
    <bug_when>2011-01-11 17:38:45 -0800</bug_when>
    <thetext>&lt;rdar://problem/8767429&gt;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>332824</commentid>
    <comment_count>2</comment_count>
    <who name="Andy Estes">aestes</who>
    <bug_when>2011-01-11 17:40:06 -0800</bug_when>
    <thetext>The removal of servePendingRequests() is what caused the Adobe Creative Suite 4 installer to break on Mac OS X.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>332825</commentid>
    <comment_count>3</comment_count>
    <who name="Andy Estes">aestes</who>
    <bug_when>2011-01-11 17:41:02 -0800</bug_when>
    <thetext>Prior to r71562, Loader::servePendingRequests() would be called as part of marking a load as finished. servePendingRequests() kicks off loads for pending requests if there are available loader slots due to the completed load. r71562 removed this call (accidentally? intentionally? sadly the ChangeLog provides no clue) as part of a refactoring, instead relying on a request timer to call servePendingRequests().

However, if a modal dialog is displayed while the request timer is active, and that dialog attempts to use resources that were previously placed in the pending queue, the load will stall since the request timer can&apos;t be started reentrantly and therefore the resources will have no way to move from the pending queue to the loader.

Restoring the call to servePendingRequests() at various points (didFinishLoading(), didFail(), didReceiveResponse()) fixes this issue.

It&apos;s not entirely clear to me how to write a test using web content that captures the nature of this bug. The key to the bug is that a timer fires which calls runJavaScriptAlert(), and Adobe has an alert delegate which then re-enters WebCore. Since a timer is firing, sharedTimerFiredInternal&apos;s reentrancy guard causes no new timers (such as m_requestTimer in ResourceLoadScheduler) to fire in the nested context.

I&apos;ve tried to approximate this using showModalDialog(), but that calls TimerBase::fireTimersInNestedEventLoop(), which resets the reentrancy guard and allows the timers to fire. I&apos;m not sure what else to try short of adding a mechanism to DRT where a test can provide a custom UI delegate for runJavaScriptAlertPanelWithMessage:</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>332827</commentid>
    <comment_count>4</comment_count>
      <attachid>78631</attachid>
    <who name="Andy Estes">aestes</who>
    <bug_when>2011-01-11 17:43:42 -0800</bug_when>
    <thetext>Created attachment 78631
Patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>332829</commentid>
    <comment_count>5</comment_count>
      <attachid>78631</attachid>
    <who name="Darin Adler">darin</who>
    <bug_when>2011-01-11 17:50:30 -0800</bug_when>
    <thetext>Comment on attachment 78631
Patch

Still worth trying to figure out if we can do a regression test for this, but that should not block checking the fix in.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>332834</commentid>
    <comment_count>6</comment_count>
    <who name="Andy Estes">aestes</who>
    <bug_when>2011-01-11 17:57:58 -0800</bug_when>
    <thetext>Committed r75580: &lt;http://trac.webkit.org/changeset/75580&gt;</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>78631</attachid>
            <date>2011-01-11 17:43:42 -0800</date>
            <delta_ts>2011-01-11 17:50:30 -0800</delta_ts>
            <desc>Patch</desc>
            <filename>bug-52264-20110111174340.patch</filename>
            <type>text/plain</type>
            <size>1844</size>
            <attacher name="Andy Estes">aestes</attacher>
            
              <data encoding="base64">SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi
Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDc1NTc2KQorKysgU291cmNlL1dlYkNvcmUvQ2hhbmdl
TG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMjIgQEAKKzIwMTEtMDEtMTEgIEFuZHkgRXN0
ZXMgIDxhZXN0ZXNAYXBwbGUuY29tPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09Q
UyEpLgorCisgICAgICAgIFJFR1JFU1NJT04gKHI3MTU2Mik6IHNlcnZlUGVuZGluZ1JlcXVlc3Rz
KCkgbm8gbG9uZ2VyIGNhbGxlZCB3aGVuCisgICAgICAgIHJlc291cmNlcyBhcmUgZG9uZSBsb2Fk
aW5nLgorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9NTIy
NjQKKyAgICAgICAgPHJkYXI6Ly9wcm9ibGVtLzg3Njc0Mjk+CisgICAgICAgIAorICAgICAgICBJ
biByNzE1NjIsIHNlcnZlUGVuZGluZ1JlcXVlc3RzKCkgaXMgbm8gbG9uZ2VyIGNhbGxlZCBpbiBM
b2FkZXIncworICAgICAgICBkaWRGaW5pc2hMb2FkaW5nKCksIGRpZEZhaWwoKSBhbmQgZGlkUmVj
ZWl2ZVJlc3BvbnNlKCkgbWV0aG9kcy4gU2luY2UKKyAgICAgICAgcjcxNTYyIHdhcyBpbnRlbmRl
ZCBvbmx5IGFzIGEgcmVmYWN0b3JpbmcsIHRoZXNlIGNhbGxzIHNob3VsZCBiZQorICAgICAgICBy
ZXN0b3JlZC4gQXQgbGVhc3Qgb25lIFdlYktpdC1iYXNlZCBNYWMgT1MgWCBhcHBsaWNhdGlvbiBy
ZWxpZXMgb24gdGhpcworICAgICAgICBmb3IgY29ycmVjdCBiZWhhdmlvci4KKworICAgICAgICAq
IGxvYWRlci9jYWNoZS9DYWNoZWRSZXNvdXJjZUxvYWRlci5jcHA6CisgICAgICAgIChXZWJDb3Jl
OjpDYWNoZWRSZXNvdXJjZUxvYWRlcjo6bG9hZERvbmUpOiBDYWxsCisgICAgICAgIHJlc291cmNl
TG9hZFNjaGVkdWxlcigpLT5zZXJ2ZVBlbmRpbmdSZXF1ZXN0cygpLgorCiAyMDExLTAxLTExICBC
cmVudCBGdWxnaGFtICA8YmZ1bGdoYW1Ad2Via2l0Lm9yZz4KIAogICAgICAgICBVbnJldmlld2Vk
IGJ1aWxkIGZpeC4KSW5kZXg6IFNvdXJjZS9XZWJDb3JlL2xvYWRlci9jYWNoZS9DYWNoZWRSZXNv
dXJjZUxvYWRlci5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291cmNlL1dlYkNvcmUvbG9hZGVyL2NhY2hl
L0NhY2hlZFJlc291cmNlTG9hZGVyLmNwcAkocmV2aXNpb24gNzU0NTQpCisrKyBTb3VyY2UvV2Vi
Q29yZS9sb2FkZXIvY2FjaGUvQ2FjaGVkUmVzb3VyY2VMb2FkZXIuY3BwCSh3b3JraW5nIGNvcHkp
CkBAIC00Myw2ICs0Myw3IEBACiAjaW5jbHVkZSAiTG9nZ2luZy5oIgogI2luY2x1ZGUgIk1lbW9y
eUNhY2hlLmgiCiAjaW5jbHVkZSAiUGluZ0xvYWRlci5oIgorI2luY2x1ZGUgIlJlc291cmNlTG9h
ZFNjaGVkdWxlci5oIgogI2luY2x1ZGUgIlNlY3VyaXR5T3JpZ2luLmgiCiAjaW5jbHVkZSAiU2V0
dGluZ3MuaCIKICNpbmNsdWRlIDx3dGYvdGV4dC9TdHJpbmdDb25jYXRlbmF0ZS5oPgpAQCAtNTIx
LDYgKzUyMiw3IEBAIHZvaWQgQ2FjaGVkUmVzb3VyY2VMb2FkZXI6OmxvYWREb25lKENhY2gKICAg
ICBpZiAoZnJhbWUoKSkKICAgICAgICAgZnJhbWUoKS0+bG9hZGVyKCktPmxvYWREb25lKCk7CiAg
ICAgY2hlY2tGb3JQZW5kaW5nUHJlbG9hZHMoKTsKKyAgICByZXNvdXJjZUxvYWRTY2hlZHVsZXIo
KS0+c2VydmVQZW5kaW5nUmVxdWVzdHMoKTsKIH0KIAogdm9pZCBDYWNoZWRSZXNvdXJjZUxvYWRl
cjo6Y2FuY2VsUmVxdWVzdHMoKQo=
</data>
<flag name="review"
          id="69981"
          type_id="1"
          status="+"
          setter="darin"
    />
          </attachment>
      

    </bug>

</bugzilla>