RESOLVED FIXED 82964
REGRESSION (r112217): H&R Block tax site won't load 
https://bugs.webkit.org/show_bug.cgi?id=82964
Summary REGRESSION (r112217): H&R Block tax site won't load
Andy Estes
Reported 2012-04-02 16:12:05 PDT
* SUMMARY H&R Block's tax website will not load in WebKit nightly builds that contain r112217. * STEPS TO REPRODUCE 1. Go to http://taxes.hrblock.com 2. Under 'New User', click 'Start Without an Account'. 3. Accept the license agreement and privacy policy and click 'Next'. * RESULTS Expected: A secure connection should be established and the site's main menu should be displayed. Actual: Nothing happens after step #3. * REGRESSION Caused by <http://trac.webkit.org/changeset/112217>.
Attachments
Proposed Patch (2.34 KB, patch)
2012-04-02 16:51 PDT, Bill Budge 		no flags
DetailsFormatted DiffDiff
Proposed Patch (7.69 KB, patch)
2012-04-02 17:33 PDT, Bill Budge 		webkit.review.bot: commit-queue-
DetailsFormatted DiffDiff
Archive of layout-test-results from ec2-cr-linux-03 (6.45 MB, application/zip)
2012-04-02 19:21 PDT, WebKit Review Bot 		no flags
Details
Proposed Patch (17.55 KB, patch)
2012-04-02 22:46 PDT, Bill Budge 		no flags
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Andy Estes
Comment 1 2012-04-02 16:13:47 PDT
<rdar://problem/11167741>
Bill Budge
Comment 2 2012-04-02 16:28:46 PDT
I am looking at it right now.
Bill Budge
Comment 3 2012-04-02 16:51:03 PDT
Created attachment 135229 [details] Proposed Patch
Adam Barth
Comment 4 2012-04-02 16:53:23 PDT
Comment on attachment 135229 [details] Proposed Patch I see. Maybe try setting a custom header and having a same-origin redirect. That will probably fail the CORS check but be allowed because it's same-origin.
Bill Budge
Comment 5 2012-04-02 17:33:49 PDT
Created attachment 135241 [details] Proposed Patch Added a test case for this. I manually verified that the code change fixes the website. I still need to verify the test.
WebKit Review Bot
Comment 6 2012-04-02 19:21:48 PDT
Comment on attachment 135241 [details] Proposed Patch Attachment 135241 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12310822 New failing tests: http/tests/xmlhttprequest/access-control-and-redirects-async.html
WebKit Review Bot
Comment 7 2012-04-02 19:21:54 PDT
Created attachment 135259 [details] Archive of layout-test-results from ec2-cr-linux-03 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-03 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Bill Budge
Comment 8 2012-04-02 22:46:37 PDT
Created attachment 135276 [details] Proposed Patch I had to do fairly extensive reworking of this patch, both code and tests. If you prefer to revert the change, don't forget the later change I made to AssociatedURLLoader and tests. http://trac.webkit.org/changeset/112485
Bill Budge
Comment 9 2012-04-02 23:23:26 PDT
The problem with 57600 is that it breaks same-origin redirects when using access control. This patch rearranges things so that same origin requests (and loaders with universal access) can proceed as before. Only if that fails do we check using access control. I tested this with the replication steps above and the website now loads.
Adam Barth
Comment 10 2012-04-03 00:55:03 PDT
Comment on attachment 135276 [details] Proposed Patch Thanks Bill!
WebKit Review Bot
Comment 11 2012-04-03 01:45:44 PDT
Comment on attachment 135276 [details] Proposed Patch Clearing flags on attachment: 135276 Committed r112997: <http://trac.webkit.org/changeset/112997>
Alexey Proskuryakov
Comment 12 2012-04-03 13:19:51 PDT
This bug is still open, can it be closed now?
Adam Barth
Comment 13 2012-04-03 15:42:35 PDT
Yes. The bot didn't close it because the 2nd patch was still marked for review.
Note You need to log in before you can comment on or make changes to this bug.