Flash Player Issue with Edge Browser in Windows 10 Anniversary Update

I recently spent a couple days debugging an issue with our Flash application in Microsoft’s Edge browser.  Several developers were updated to the Anniversary update for Windows 10 and if you tried to load the page with our Flash application it wouldn’t display and right clicking would show the “Movie not loaded” message.  Everything worked fined in Chrome, IE and Firefox.  I verified that Flash applications on the internet worked to eliminate that part of the problem.

Things go weird when I tried accessing the application from a different machine and it worked fine.  Further testing showed that the application would load fine on port 80, but not port 8080.  I was really narrowing it down and finally found that in the Anniversary update a new setting was added to the about:flags page called “Allow Adobe Flash Player localhost loopback”.  After turning this on and restarting the browser the application loaded fine.  

Downgrade Flash Player in Google Chrome

Time to Downgrade

In a post earlier this week, Flash Problems, I talked about an issue I ran into with a recent Flash Player update that caused problems in the application I work on. After tracking down the problematic code I was able to fix it to get around the problem so going forward things should be fine. However, since it is an enterprise application that is installed and maintained by the user I can’t just push a patch out to a web server and move on to the next fire. The bug will only affect users with the latest version of Flash Player,, in the past that may not be a big deal because most users wouldn’t install every update that was released, but since Flash has had so many security vulnerabilities it is more likely people will have the latest version.

Google Chrome and Flash Player

In the case of Google Chrome though the user being up to date is almost a certainty, because not only does it ship with its own Flash Player, but there is no way via settings to disable Flash Player updates or switch to a different Flash Player version. Don’t get me wrong I think this is great, users should have the most up to date version with all the latest security vulnerabilities patched. If Flash Player didn’t have so many problems it probably wouldn’t have found itself so tightly constrained. Over the last couple years Chrome has slowly removed support for NPAPI plugins in favor of PPAPI, because the latter sandboxes the plugin and makes it more secure. It had been possible to install an NPAPI Flash Player from Adobe onto a system and then disable the built in Chrome Flash Player for purposes of testing or downgrading, you could even enable and disable the different versions of Flash Player from the plugins settings page. However, with the removal of NPAPI support this is no longer an option, which I found out yesterday. The Adobe instructions for installing an alternate version of Flash Player are outdated and still reference the old way. One thing that has changed over the last year is that Adobe now ships a PPAPI version of Flash Player for Chromium browsers, this was the key to solving my problem. I knew that the developers of Chrome may not want other developers to install an NPAPI Flash Player, but they would definitely allow the installation of an older version of a PPAPI Flash Player. They know we gotta debug issues in old versions of Flash Player somehow. Here are those instructions

Downgrade Steps

Download Installer

First you will need to download the installer for the old version of Flash Player you want to use.
  1. All previous version of Flash Player can be found at Flash Player Old Versions Download site
  2. You can find the zip files for the versions in the Flash Player Archives section
  3. Download the version you want to your desktop

Uninstall Flash Player

In order to downgrade Flash Player you must first uninstall any newer versions.
  1. Close any web browsers open on your system
  2. Extract the contents of the zip file.
  3. In the extracted folder, navigate to the folder that doesn’t have “debug” in the name it will contain all the installers and the uninstaller.
  4. Double-click the uninstaller that ends with win.exe. You will be prompte to uninstall the current version of Flash Player for all browsers.
  5. Click Start in the pop up
  6. When it is complete click Done to dismiss the pop up

Install Flash Player for Google Chrome

After Flash Player has been uninstalled, you will need to install the Pepper (PPAPI) Flash Player.
  1. Navigate to the folder where you ran the uninstaller
  2. Run the Pepper installer which is the one that ends with WinPep.exe to install Flash Player for Google Chrome. Flash Player will be installed at the operating system level and will be separate from the version installed with Google Chrome.
  3. Accept the license agreement
  4. Click Install to start the installation
  5. After the installation is done select the Never Check for Updates options and click Done to close the installer

Disable the Chrome Flash Player

Now that you have installed the PPAPI Flash Player into Windows you have to disable the Flash Player that is included in Google Chrome. This is done via a command line argument when launching Google Chrome
  1. Right click on the icon used to launch Google Chrome
  2. Select the Properties option to view the properties for the Shortcut
  3. Go to the Shortcut tab in the properties view
  4. In the Target field add –disable-bundled-ppapi-flash after the closing double quote that wraps the path to chrome.exe. The new value for the target field should be something like this “C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” -disable-bundled-ppapi-flash
  5. Click OK to save the changes

Verify Installed version

Repeat the initial instructions to verify that the version of Flash Player is now correct in your browser
  1. Open up Google Chrome using the shortcut
  2. Go to chrome://plugins
  3. Expand the Details link at the top right corner to see the details of all the plugins
  4. Look at the Flash Player version it should now have a location that points to the Windows Flash Player rather than a Flash Player inside the Google Chrome installation directory.

Flash Problems

Works for Me

Last week I received an email from a QA resource who was getting an error in the Flash Player debugger when performing a very basic action in our Flash application. I quickly looked at the stack trace he provided and tried to reproduce the issue without much luck. I didn’t think anything of it since sometimes QA environments have been known to be suspect.

Fast forward a week and I was pulled into an urgent customer issue, where they were seeing the application become unresponsive when performing some very basic tasks. I logged into the system, where the error was occurring, using IE 11 which has a debugger version of Flash Player and everything worked fine. I then tried it out with Chrome and was easily able to reproduce the issue, same thing with Firefox. I then tried the same thing on a local developer build and got the same results, at first glance there seemed to be a problem with the debugger version of Flash Player. It seemed odd, but they are slightly different versions of Flash Player and it wouldn’t be unheard of.

I spent the next several hours trying pinpoint the issue using Flash Builder and Google Chrome. I was able to comment out some code to make the issue go away, but it wasn’t immediately obvious where things were going wrong. I then remembered that my debugger version of Flash Player was several versions older than the auto updated version in Chrome, version 17 vs version 20. I upgraded the Flash version in IE up to the last release from February 9th, not coincidentally this was the day before the customer saw the issue. To my surprise I was able to reproduce the error and since I was using the debugger version of Flash was shown a stack trace which led me directly to the problem.

The Error

ArgumentError: Error #1508: The value specified for argument RectangleObject is invalid.
at flash.display::DisplayObject/set scrollRect()
at spark.components.supportClasses::GroupBase/set scrollRect()
at spark.components::Group/set scrollRect()
at spark.layouts.supportClasses::LayoutBase/updateScrollRect()
at spark.layouts.supportClasses::LayoutBase/scrollPositionChanged()
at spark.layouts.supportClasses::LayoutBase/set horizontalScrollPosition()
at spark.layouts.supportClasses::LayoutBase/set horizontalScrollPosition()
at spark.components.supportClasses::GroupBase/set horizontalScrollPosition()
at spark.components.supportClasses::GroupBase/set horizontalScrollPosition()

The error was occurring when we were setting the horizontalScrollPosition on a scroller to a very large number (int.MAX_VALUE to be exact). Now I know using this value is not a good idea and should be a red flag, but Flash Player had been okay with it up until the latest version. I installed the version from late January and didn’t have a problem, so it was tied directly to version I looked at the release notes from Adobe, but nothing jumped out at me. It looks like for some reason they added some new validation for the Rectangle object that is passed into DisplayObject.scrollRect() to now throw an error. Of course since Flash Player is closed software I will never know what the limits are for the horizontal scroll position.

The Fix

Since I knew what was going on I was quickly able to commit a fix, which now sets the scroll position to the width of the viewport rather than the maximum integer value. However, the code fix wasn’t going to help the version of the software that had already been released. Since Flash has had so many security problems most browsers now will automatically update, which is why this happened in the first place. The workaround is to uninstall the current version and downgrade to the previous version and shut off automatic updates. In the case of Chrome it is not possible to shut off automatic updates for the Flash Player included with the browser, instead you have to install a separate install of Flash Player, disable the default and enable the new install.

Moving From Adobe Flex 4.6 to Apache Flex 4.13 with FlexMojos

I was very excited for the handover of the Flex project from Adobe to an Apache project.  After a few years I was finally given permission to move our product from Adobe Flex 4.6 to Apache Flex 4.13.  Here are my notes on the process in the hopes that they help somebody else in the same situation.

For some background our product was compiling using FlexMojos 4.0-RC1 and Adobe Flex version 4.6.  I decided to go with the least moving parts approach, which meant I made the upgrade in two steps.  First I upgraded the FlexMojos version to version 6.0.1 and then I upgraded to FlexMojos 7.0.1 and Apache Flex 4.13.

Up first was the upgrade to FlexMojos 6.0.1.  This version of FlexMojos supports both Adobe and Apache SDK’s, but due to difficulties in supporting two different group ids, it uses the com.adobe groupID for all types of artifacts.   I followed details available on FlexMojos 6.0 wiki page and its child page specifically for migrating to FlexMojos 6.

  1. Upgrade to Maven 3.0.5 (required for FM6)
  2. Changed the FlexMojos version property in my parent pom file to 6.0.1
  3. Changed the group id for the FlexMojos plugin from org.sontaype.flexmojos to net.flexmojos.oss
  4. Update the playerglobal dependency 
    1. Group ID = com.adobe.flash.framework
    2. Artifact ID = playerglobal
    3. Remove version that points to Flex SDK
    4. Update classifier tags to version
Once I made these small changes I was up and running with the new improved FlexMojos 6.0.1.  After that I moved on to the bigger task of Apache Flex 4.13.  I downloaded the Apache Flex installer and installed the SDK locally and then used the Apache Flex mavenizer, lots of details on that in the Apache Flex Wiki. I won’t go into details, but I basically downloaded the source for the project and build the maven deployer.  Since I wanted to test locally I did modify the deployer slightly so it would just install the artifacts to my local repository first.  Overall it was pretty straightforward.

Next I updated my various pom files for FlexMojos 7.0.1 and Apache Flex 4.13.  Here are the steps:
  1. Update the flexmojo.version property in the root pom to 7.0.1
  2. Update the flex sdk version property in the root pom to
  3. Updated the old groupID of com.adobe.flex to org.apache.flex for several dependencies.  In my case there were some instances where the old group id was valid because I had some automation libraries that I still don’t have artifacts for and also for some exclusions.
  4. Remove the license jar dependency.
  5. Updated the flexframework artifact name to framework and fixed the group id for it to org.apache.flex
  6. Updated the theme dependency so it doesn’t have a classifier and instead of the type being css it is now swc.
  7. Updated the theme dependency’s group id to org.apache.flex.framework.themes
  8. Updated all the Flex dependencies from the scope of “caching” to “rsl”, because there aren’t any swz files for Apache Flex libraries
  9. Updated the group id for all automation libraries to org.apache.flex.framework.automation
  10. Remove the “_rb” from the automation artifact names and added a new classifier of “.rb”
All of the above changes got me 99% of the way there and I was able to build the project successfully with Maven, unfortunately I ended up with a runtime problem.

When loading the application in a browser I received the dreaded VerifyError 1053 “invalid override of the removeItem() method.  As it turns out the third party library I was using had a removeItem() method on a class that extended from ListCollectionView AND in the same method was added to Apache Flex 4.10.  

Of course I didn’t just take the error message at its face value and spent a few days trying to figure out the problem.  Once I did it was just a matter of downloading the source for the specific version of the third party library, changing the name of the method, rebuilding a “new” version and deploying it to my maven repository.  Of course if I didn’t have access to the source I would have been in trouble. After that the application behaved as it did before the upgrade.