APM has one deployment mode called "Portal Access" or "Rewrite" that uses an extremely complicated reverse proxy engine. Portal Access intercepts all javascript code and rewrites (or at least tries to) all functions that the browser uses to do network activity into special F5 functions and methods that, ideally, can duplicate the functionality of the original. As new versions of ECMAscript have been rapidly adding a lot of extra methods and functionality, it's been difficult to adapt APM to. Older versions of this Portal Access did the same rewriting-functions (with added decompile/compile steps) to Flash content and Java content.
The reason that Portal Access was created in the first place was because legacy java, web, and flash apps tended to have a lot of different backend servers running on various ports, and it was impossible to publish them all on the same DNS endpoint.
Nowadays these concerns are less, and it's usually much easier to move web apps from one hostname to another. Web apps tend to use just a single endpoint to make the app easier to deploy.
We don't recommend deploying new apps with Portal Access on APM, because of the kinds of compatibility problems you're discovering. Instead, just publish the apps on a virtual server, make sure it works without APM, then add an APM access policy to it.
We understand that these kinds of problems are frustrating, and I hope that this explanation helps. We intend to publish a document specifically about migrating Portal Access mode to Web Access Management (LTM+APM) mode in the near future.
Nimbostratus
