SWF file is not displaying in browser

Here's what's going on:

There's a SWF called AIR.swf that's included in the AIR SDK that makes a number of functions available for developers that are intended to tell you about the availability of AIR on a given client machine.

Flash Player is supposed to inspect the machine and determine if AIR is present, and that worked and made a lot of sense 6-7 years ago when it was implemented, but tightening browser sandboxes have restricted Flash Player's ability to reliably conduct those inspections.

In the case of Firefox, there's a very large difference between 32-bit Firefox on Windows and 64-bit Firefox on Windows, in that 64-bit Firefox contains a native NPAPI sandbox.  For historical reasons, Mozilla did not ship an NPAPI sandbox on 32-bit Windows, so we wrote our own, and tacked a Flash sandbox on to the back side of the NPAPI interface.  We had a little more insight into our business needs than Mozilla does, so we made appropriate affordances to keep those things working.

Mozilla has largely committed to 64-bit Firefox, and it's the default version served to Windows users at this point; however, if you already have a 32-bit Firefox installed on a 64-bit operating system, I don't think that they'll change the installed version.  I don't have a lot of insight into their release and update strategy, but that approach may have changed.  In general, 64-bit Firefox performs better, and is more stable and secure, so pushing users to it would make a lot of sense.

The test data that was provided above is inaccurate, and I suspect that the results are muddied by testing across multiple machines with a mix of 32 and 64-bit Firefox.   It not that the SWF wasn't loading, but that the call to airSWF.getStatus() returns an inaccurate result.

Here's the result set from our triage, which aligns better with my intuition:

FAIL - Firefox 56.0.2 (64-bit) on Win7 x64 with Flash Player 27.0.0.183, 24.0.0.221, 25.0.0.127

PASS - Firefox 56.0.2 (32-bit) on Win7 x64 with Flash Player 27.0.0.183, 24.0.0.221, 25.0.0.127

PASS - Firefox 58.0a1 (2017-10-16) (32-bit) on Win7 x64 with Flash Player 27.0.0.183

FAIL - Firefox 58.0a1 (2017-11-02) (64-bit) on Win7 x64 with Flash Player 27.0.0.183

FAIL - Chrome Version 61.0.3163.100 (Official Build) (64-bit) on Win7 x64 with Flash Player 27.0.0.183

PASS - Internet Explorer 11 on Win7 x64 with Flash Player 27.0.0.183

What you'll see across the Firefox data, is that the behavior doesn't break across Flash Player versions, but across the sandbox variant employed.

It's also the case that Chrome (and I suspect Edge, but haven't tested it yet) also employ a sandbox that restricts Flash Player's ability to inspect the system for the presence of AIR and correctly return a result.  In the grander scheme of things, reducing Flash Player's access to the broader system a good thing, since it's primary job is processing untrusted content.

So, the state of affairs is that this functionality is pretty fragmented across the existing body of supported browser/os combinations.  In order to correct it (we're always shooting for platform parity, it's basically our reason for existing), we'll have to negotiate with each individual browser vendor to loosen that constraint such that we can provide an authoritative answer.

I'll open a copy of this bug up internally so that we can discuss it as a larger engineering management team, but I can pretty definitively tell you that any resolution for this will be slow at best, just because of the number of organizations involved and the priority that this issue would take in their larger scheme of individual engineering priorities.

In terms of your immediate needs, you're probably better off adapting your interaction workflow to a world where you can't reliably detect the AIR shared runtime from Flash Player, either by adopting a captive runtime strategy, or walking users through the shared runtime installation in a more explicit way.

Honestly, I don't understand what I'm looking at, or what your original request was looking for.

Are you sure that the SWF works when run locally (or from a local webserver)?  When I drag the box, nothing happens, except that I see a little orange icon underneath.

Given the 24-hour response cycle, I don't thing it's helping you to continue to go back and forth with one-sentence answers.  I think it would be worth your time to write up an actual bug report that I can follow, that includes steps to reproduce, and actual and expected results, with screenshots, if applicable. 

You can file a bug over http://tracker.adobe.com/.

At this point, I'm just trying to understand what the bug is that you're trying to report.  I've spent enough time on this to have solved it at this point, and I still have no idea what I'm looking at.

Your original post doesn't make any sense to me, and I simply don't understand what you need from us.

I have sent you a release build of  swf file in a message. When we try to run the swf file via web application it checks the air run time has installed or not and gives the status as "Available". We have installed adobe air and current version is 27.0.0.124. Since the application is a web distribution is that enough to go only with air installation?

What are you trying to accomplish, and what, specifically, doesn't work?

First things first, try 27.0.0.183.  If that doesn't work, we'll need to debug it to understand why it's crashing.

You attached an image, but not a SWF.  If you can post a publicly accessible link that demonstrates the problem, and step by step instructions on how to reproduce the crash, that would be ideal.  If you can't share a link, you can upload the actual SWF to Adobe Send, Dropbox, Google Drive, etc. and share a link to the download and post it in a reply to the forums, assuming that it will demonstrate the problem when run locally or from a local webserver.

If you'd prefer to keep that content private, you're welcome to send me a private message (just click my name) with the link instead.

Hi,

Please try 27.0.0.183, released earlier this morning.

--

Maria