Is this similar to  Issue 10544  ?

Yes, this seems to be the same bug, and it's reproducible in the latest 2.0 release.

if it was fixed for the 3.0 brunch, maybe it should be considered for the stable one 
too?

Eric, we will need to patch the stable release with whatever changed between 2 and 3.

@orktchromebug: Thankyou for the concise and useful repro steps!

This appears to be a regression in WebKit.

Which was subsequently fixed in 3.0 by r16332 which updated our WebKit from 
[43806:43832].

This was how WebKit fixed it:

http://trac.webkit.org/changeset/43831/trunk/WebCore/loader/DocLoader.cpp?
old=42896&old_path=trunk/WebCore/loader/DocLoader.cpp

http://trac.webkit.org/changeset/43831

We should pull that same change into the 2.0 branch... However I don't know what the 
process will be like to do that, since I just want to change that 1 file, and not 
pull in any of the new goop.

Adding dglazkov in case he has ideas on how to pull just that change into 2.0 branch.

Actually adding dglazkov this time :)
@dglazkov: how can I pull just this one change into the 2.0 branch?

I guess we will just have to wait for 3.0 to push this fix, unless we have ability to fork webkit in our release 
branch.

The fix itself is really simple:

$ gsvn diff third_party/WebKit/WebCore/loader/DocLoader.cpp
Index: third_party/WebKit/WebCore/loader/DocLoader.cpp
===================================================================
--- third_party/WebKit/WebCore/loader/DocLoader.cpp     (revision 18722)
+++ third_party/WebKit/WebCore/loader/DocLoader.cpp     (working copy)
@@ -344,7 +344,8 @@
         return;
     for (unsigned i = 0; i < count; ++i) {
         PendingPreload& preload = m_pendingPreloads[i];
-        requestPreload(preload.m_type, preload.m_url, preload.m_charset);
+        if (!cachedResource(m_doc->completeURL(preload.m_url)))
+            requestPreload(preload.m_type, preload.m_url, preload.m_charset);
     }
     m_pendingPreloads.clear();
 }


However if my only recourse is to update the DEPS for WebKit to get this, I will be pulling 1,700+ revisions of 
unholy goodness. (2.0.172.33 is using WebCore@42115; the fix was landed in WebCore@43831)

(No comment was entered for this change.)

Ok, Mark showed me that we have a local copy of webkit for the releases, so not a 
problem. Mark is backporting.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=19578 

------------------------------------------------------------------------
r19578 | mal@chromium.org | 2009-06-29 22:15:50 -0700 (Mon, 29 Jun 2009) | 7 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/WebKit/172/WebCore/loader/DocLoader.cpp?r1=19578&r2=19577
   M http://src.chromium.org/viewvc/chrome/branches/WebKit/172/WebCore/loader/FrameLoader.cpp?r1=19578&r2=19577

Port WebKit r43831 to 172.

Fix CAPTCHAs.

Bug= http://crbug.com/15569
TBR= eroman
Review URL: http://codereview.chromium.org/151068
------------------------------------------------------------------------

Fixed in 172 branch @ r19578.

That was fast, thanks for the fix :).

Verified in build 2.0.172.37 (Official Build ) and 3.0.195.0 (Developer Build 20619),
works fine now.

would this be similar to the one I reported a few months ago? The  issue 14050  http://code.google.com/p/chromium/issues/detail?id=14050 is still unconfirmed ...

I mean, if you guys could do such a great and fast job in this issue, can't anyone take 
a look in the other one? Is there more information I can share to make it easier to 
detect or any kind of help I could give to you? 

Thanks, Rick

(No comment was entered for this change.)