Fluorine request not being made in some IE versions

325 views Asked by At

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.getCaptchaAgain.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?

1

There are 1 answers

0
Owen Blacker On BEST ANSWER

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!