New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 15569 link

Starred by 3 users

Issue metadata

Status: Verified
Owner:
Closed: Jun 2009
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

Images are fetched twice, breaking captchas on orkut.com

Reported by orktchro...@gmail.com, Jun 29 2009

Issue description

Chrome Version       : 2.0.127.33 (Official Build )
URLs (if applicable) : See steps below
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: OK
  Firefox 3.x: OK
         IE 7: OK
         IE 8: OK

What steps will reproduce the problem?
1.Login to orkut.com with user "orktchromebug@gmail.com", password 
"orangeblue". (This is a demo account for your convenience, you may use 
your own account.)
2.Navigate to this URL "http://www.orkut.co.in/Main#CommMsgPost.aspx?
cmm=39966102&tid=5352634947283850117". (Again this link is for your 
convenience, you may post to any Orkut community.)
3.Enter any string with a URL such as "google.com" in the "Message" field 
and click on submit.
4.You will see a captcha image. Try answering the captcha.
5.Your captcha answer will not be accepted, even if it is correct.

What is the expected result?
The captcha answer should be accepted.

What happens instead?
Correct captcha answers are not accepted even on repeated attempts.

Explanation:
After some digging I discovered that Chrome 2.0 fetches the captcha image 
twice, and renders only the result of the former fetch. This can be 
verified by using Wireshark to monitor the HTTP requests while performing 
the above steps. For your reference, the captcha image is an image tag of 
the form <img src="http://www.orkut.com/CaptchaImage?xid=...">.

On our server (i.e. Orkut) a new captcha string is generated for the user 
for every fetch of the captcha image (since it is a request to the 
/CaptchaImage servlet). Thus the user ends up seeing the wrong captcha 
image (because they are shown the earlier fetched image, not the later 
one). Note that this is not reproducible on the latest Chrome 1.0 or 3.0 
builds.
 

Comment 1 by dhw@chromium.org, Jun 29 2009

Is this similar to  Issue 10544  ?

Comment 2 by de.ari...@gmail.com, Jun 29 2009

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?

Comment 4 by jon@chromium.org, Jun 29 2009

Labels: -Pri-2 -Area-Misc Pri-1 Area-BrowserBackend Mstone-2.0 Channel-Stable
Status: Assigned
Eric, we will need to patch the stable release with whatever changed between 2 and 3.

Comment 5 by eroman@chromium.org, Jun 30 2009

Status: Started
@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.

Comment 6 by eroman@chromium.org, Jun 30 2009

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

Comment 7 by eroman@chromium.org, Jun 30 2009

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)

Comment 8 by eroman@chromium.org, Jun 30 2009

Summary: Images are fetched twice, breaking captchas on orkut.com

Comment 9 by eroman@chromium.org, Jun 30 2009

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
------------------------------------------------------------------------

Status: Fixed
Fixed in 172 branch @ r19578.
That was fast, thanks for the fix :).

Comment 13 by *mdu@chromium.org, Jul 14 2009

Status: Verified
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
Labels: -Area-BrowserBackend Area-Internals
Project Member

Comment 16 by bugdroid1@chromium.org, Oct 12 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 17 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals Cr-Internals

Sign in to add a comment