Skip to main content
K
kobo02
Participating Frequently
December 9, 2015
Question

Flash Player 20 playback issue on ActiveX (v20.0.0.228)

  • December 9, 2015
  • 3 replies
  • 9994 views

We are using the Flash Player ActiveX in our vb.net application.

As a result of updates to 20.0.0.228 version of Flash Player, it is not possible to play.


The swf path is "file:///e:/movie/test.swf" or "file://server/movie/test.swf".
This works with previous version of Flash Player, but latest version (20.0.0.228) cannot play.

The swf path is "e:\movie\test.swf" or "\\server\movie\test.swf".
This works both of version.

I want to know whether this be fixed in the bug, or whether a specification.
I hope to be able to play all kinds path, include "file:///e:/movie/test.swf".
    This topic has been closed for replies.

    3 replies

    pavelr21055322
    pavelr21055322
    New Participant
    December 30, 2015

    Jeromie, thank you for the prompt reaction to the incident.

    I have tried out the BETA version of FP.

    The error is fixed, thank you.

    I have a number of questions regarding the present and the future.

    1. The newest Flash Player 20.0.0.267 is being rolled out to the users computers right now.

    It has the defect.

    Today I have received a ton of emails from people who are not able to run our application.

    Their FPs have upgraded to 267 automatically.

    Can you pause the rollout of the problematic 267 build?

    Please, pause it.

    Until the current BETA is ready for the release.

    2. I need to tell YoWindow Weather users when the problem to be fixed.

    When are you going to release the current BETA of Flash Player?

    3. I wonder what are we going to do to avoid such an incident in the future?

    I'm thinking about to go AIR way.

    But can we compile AIR app to screen-saver?

    jeromiec83223024
    Community Manager
    jeromiec83223024Community Manager
    Community Manager
    December 31, 2015

    The current release is a response to a security exploit in the wild that we were forced to address quickly.  It went out on Monday, so it should have patched the vast majority of your users already.  Our priority will always be the security of the web browser, and our approach in these situations is to remediate the immediate threat while hopefully not breaking anything, and then to deal with any unanticipated/undiscovered functional fallout when it arises. The issue you're experiencing is a functional issue that was fallout from having to push that release prematurely.

    We're currently aware of a cluster of bugs impacting the embedded OCX use-case, and are actively investigating.  I don't make promises that I can't keep, so I'm not going to talk about dates, but we're doing our best to provide an expedient fix in the form of a production release.

    Adobe's US offices are closed for the US holidays, which is slowing down the response.  People and systems are unavailable due to vacation travel, scheduled maintenance, etc.  Fortunately, we're all back in the office on Monday and should have critical mass.  In the meantime, we're already conducting the analysis and considering the logistics of what can be fixed, when.  I expect it to be a fairly quick turnaround.

    Hope that helps.

    K
    kobo02Author
    Participating Frequently
    January 17, 2016

    Adobe is planning to push an update (20.0.0.286) through the Adobe servers on Tuesday, January 19th.  This update will apply to OSX NPAPI and Windows XP - Windows 7 NPAPI, ActiveX and PPAPI.  We are also coordinating with Google to push out a component update for Chrome at or around the same time.  Updates for Microsoft IE on Windows 8.1 and Microsoft IE and Edge on Windows 10 should occur on the scheduled February 9th update via Windows Update.

    Thanks


    Please confirm operation of FP enough before releasing it.

    If a problem happens next, it is the third time.

    Our customer does not forgive our product.

    pavelr21055322
    pavelr21055322
    New Participant
    December 29, 2015

    “You become responsible, forever, for what you have tamed.”
    ― Antoine de Saint-Exupéry, The Little Prince

    I'm am an author of YoWindow Weather app/screensaver - http://yowindow.com

    YoWindow is a well known application for Windows and Mac.

    For example, #1 Screen saver in Germany

    Screensaver - Downloads - CHIP


    YoWindow has fallen as a victim of this modification.

    Since the release of FP 20.0.0.267 we are receiving complaints that YoWindow is not working anymore.

    Most users will soon be unable to run the app and screen saver.


    We use ActiveX instead of AIR because AIR is not able to run as a screen-saver.


    We've been working on YoWindow Weather since 2006.

    I wonder if this is the end of the line?

    Should we close down the project?

    Pavel Repkin

    jeromiec83223024
    Community Manager
    jeromiec83223024Community Manager
    Community Manager
    December 30, 2015

    I believe that the candidate fix is available in the current beta, here:

    http://www.adobe.com/go/flashplayerbeta/

    To answer your question more directly, embedding ActiveX controls into standalone applications is not guaranteed to be viable over the long term.  We don't technically support the use-case now, although we're aware that there's a body of legacy applications that take advantage of this approach, and we do our best to do right by the developers that have invested in the Flash platform over the years, and that still use this approach. 

    That said, we don't actively test this use-case, although we do try to fix it if and when things break.  If faced with a choice between security in the browser plug-in case and the application case, we'll choose the browser plug-in. 

    As the security landscape continues to evolve and become more challenging, we're often faced with decisions for which we cannot anticipate all of the potential side-effects, and the nature of those issues frequently does not afford us the luxury of a slow and measured response. 

    I
    ivanp61579321
    Participating Frequently
    December 30, 2015

    Jeromie, as I stated in https://bugbase.adobe.com/index.cfm?event=selectBug&CFGRIDKEY=4101067:

    "Just tried Beta Dec 16, 2015 from http://www.adobe.com/go/flashplayerbeta/ on Windows 7 and the issue is still present."

    This is not security related issue, but a critical bug ('blocker') affecting all developers like us, which tied their products with Adobe's technology for over 10 years.

    It would be nice to add this use-case as a test unit, since it is part of official documentation "Absolute URLs must include the protocol reference, such as http:// or file:///":

    http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00000573.html

    K
    Community Manager
    Kratika AgarwalCommunity Manager
    Community Manager
    December 9, 2015

    Hi,

    Thanks for reporting the issue.Could you please share your swf file so that we can verify the issue.

    Is it working on other browsers other than ActiveX.

    K
    kobo02Author
    Participating Frequently
    December 9, 2015

    thanks

    I cannot provide the swf file because it's a part of commercial application.

    but, you can reproduce using sameple swf file of adobe site below.

    https://www.adobe.com/support/documentation/en/flash/fl8/samples.html

    Click "alpha video sample files" for download.

    1.

    AxShockwaveFlash1.Movie = "file:///d:/movie/ClearExternalNoVol.swf"

    -> Cannot play. screen is white.

    2.

    AxShockwaveFlash1.Movie = "d:/ClearExternalNoVol.swf"

    -> Can play normally

    *

    I was confirmed by IE but it can play normaly.

    (IE cannot use URL, such as "file:///d:/...". It is automatically converted to "d:/...".)

    jeromiec83223024
    Community Manager
    jeromiec83223024Community Manager
    Community Manager
    December 10, 2015

    We continue to be forced to lock down the ability to for SWF files running in the local filesystem to access external resources for security reasons.  Personally, I would like us to retire this functionality altogether, and newer browsers like Edge already impose those restrictions at the browser.

    The issue you're experiencing with URL resolution lies at the intersection of a valid pseudo-protocol and the ability to abuse it by taking advantage of the overly-permissive interpretations of similar URLs by some browsers.  While it's unlikely but possible that we may change this behavior to fix the issue, it's probably just going to be a continued source of pain for you.

    You're far, far better of either hosting the SWF on a web server (even a local one), or by packaging your content as a desktop Adobe AIR application, which exists to address the local application use-case, and is a far better choice for this kind of approach.

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices