Luckily, we were able to reproduce the problem on one of our test machines (though not on another, which made things more frustrating interesting). The difference ended up being in the security settings, specifically the "allow sub-frames to navigate across different domains" setting.
To make a long story short, our issue was to do with how we were setting the src attribute on the hidden iframe. When we enabled Asset Hosts, our source attribute was an absolute path to one of the asset hosts:
<iframe ... src="http://asset2.scoodi.com/path/blank.html">
Going back to the security setting, in our case, it was saying you can't submit a form served from www.scoodi.com to a target frame served from asset2.scoodi.com. When the setting was enforced, it raised an "access denied" error from the line of JavaScript that submits the form.
Once we worked out the problem, the fix was simple: make sure the iframe src attribute uses the same domain as the page source. In our case, it was as easy as using a path relative to the server:
<iframe ... src="/path/blank.html">
It was no coincidence that the bug appeared with the increasing number of users to the site, though it wasn't because we were getting a wider range of browsers and configuration permutations. We enabled Asset Hosts because of the increase in users, and when we did that, those IE6 browsers with higher security settings stopped working.
No comments:
Post a Comment