Fluorine request not being made in some IE versions
We have a really strange problem with a piece of Fluorine integration we've built.
We have a form with a Captcha on it; the Captcha image is populated from a .Net/AMF webservice inventively titled GetCaptchaImage.ashx
and can be reloaded from a text hyperlink within the Flash.
In some versions of IE (particularly IE8, but it may also be others), irrespective of IE version emulation and wmode, clicking the text link causes the HTTP call to our Fluorine gateway successfully to be made, but the call to the webservice does not follow it. Inspecting the HTTP transactions with Microsoft Fiddler, we see:
POST http://www.domain.com/gateway.aspx
200 OK (application/x-amf)
and nothing else, whereas in any other browser we see:
POST http://www.domain.com/gateway.aspx
200 OK (application/x-amf)
GET http://www.domain.com/GetCaptchaImage.ashx
200 OK (image/gif)
The code that makes the call appears to be inherited, without any override, from org.osflash.signals.Signal.dispatch
, so I can't see why it wouldn't Just Bloody Work™. The actual method call reads:
private function getNewCaptcha(event:MouseEvent):void
{
getCaptchaAgain.dispatch();
trace("Captcha button click");
GlobalDebugger.log(this, "Captcha button click!");
}
where the only other mentions of getCaptchaAgain
in the entire codebase are:
public var getCaptchaAgain:Signal = new Signal();
and
compForm.get开发者_StackOverflowCaptchaAgain.add(getTheCaptchaAgain);
and the only other occurrence of getNewCaptcha
is the line:
_cantReadCaptchaButton.addEventListener(MouseEvent.CLICK, getNewCaptcha);
Edit: Juan Pablo Califano pointed out I'd failed to notice that there was a reference to getTheCaptchaAgain
, which I'd misread as getCaptchaAgain
. It is defined as
private function getTheCaptchaAgain():void
{
captchaSignal.dispatch();
}
and is only called from onFormResponse
, where it is uninteresting. captchaSignal
is defined in
public class CompetitionFormMediator extends AbstractFactoryAccessorMediator
{
[Inject]
public var captchaSignal:CaptchaSignal;
// ...
}
CaptchaSignal
extends org.osflash.signals.Signal
and is uninteresting but is called in a line reading:
signalCommandMap.mapSignalClass(CaptchaSignal, CaptchaCommand);
CaptchaCommand
extends SignalCommand
and ends up inside flash.events.EventDispatcher
calling
var callFunction:Function = serviceHub.call;
callFunction.apply(serviceHub, collectArgs);
where collectArgs
is an Array
of arguments that don't offer any clues.
End edit
Does anyone have any idea why on earth that second call wouldn't be making it to the webserver? I can't see why the Flash wouldn't be issuing the HTTP GET
but, equally, I can't think of any reason why a browser (let alone just this browser) would be suppressing it. I'm not a Flash developer (I run the .Net team here), but I can't see anything odd there and neither I nor the Flash team (including the developer who built the code) can think of any reason why this might be happening.
Any ideas anyone?
After all that, it looks like it was a problem elsewhere in the Flash, and the handler in question (/GetCaptchaImage.ashx
) being considered unchanged by the browser.
So we've solved the problem with caching settings, rather than needing to do much else.
Thanks for your help everyone, particularly Juan Pablo!
精彩评论