New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 826453 link

Starred by 5 users

Issue metadata

Status: Unconfirmed
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

The unsandboxing utility provided by Flash stopped working properly.

Reported by jdu...@juno.com, Mar 27 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce the problem:
Snap-on Business solutions provides a Flash-based application to customers over the Internet.  Customers use various browser of choice to access the application, including Chrome.  The application supports tight integration with 3rd party applications and requires unsandboxing to use Flash features to communicate with those applications.

Beginning 3/25/2018, our customers began experiencing problems with our application.  The unsandboxing utility provided by Flash stopped working properly.  The users are experiencing a pop-up dialog repeated that they normally ever only see once.  This pop-up, normally only seen the very first time a user uses the site, states "To use this application in Chrome, you need to enable extra features in Adobe Flash.  Would you like to enable them now?"  After clicking Yes, the user is prompted with an error.  This particular pop-up states "Couldn't write the application to the hard disk.  Please verify the hard disk is available and try again."  The cycle of these two pop-ups continue until the user gives up by clicking No or Cancel on one of the two pop-ups.

The attached source code is an example that can be used to generate the issue.  The issue we believe is first on line 30, as _pm.installed always returns false, whereas before the issue started presenting, the _pm.installed would return true if the user had accepted the unsandboxing on a previous run of our application.  The second issue - the extra pop-up indicating a problem writing to the hard disk - occurs at line 66 after calling _pm.download().

We believe something has changed in PepperFlash 29 or something related to Chrome 65 that is causing this problem suddenly.

What is the expected behavior?

What went wrong?
Please let us know how to remedy this problem as we are experiencing a high volume of support calls and we are having to direct users away from Chrome to solve the problem.

Did this work before? Yes Chrome 64 as of 3/24/2018

Does this work in other browsers? Yes

Chrome version: 65.0.3325.181  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 29.0 r0
 
ChromeBugReport_20180327.zip
16.4 KB Download
Labels: Needs-Triage-M65 Needs-Bisect
Components: Internals>Plugins>Flash
Labels: -Hotlist-Interop
Labels: Triaged-ET Needs-Feedback
Thanks for filing the issue.

@Reporter: If possible could you please share sample externally shareable URL which can be used to test and confirm the regression from TE's end.

Thanks!

Comment 4 by jdu...@juno.com, Mar 28 2018

It will be difficult to provide you access to our application without exposing our IP to the internet.  Would you be able to do a live web-ex demonstration of the behavior?  I could also provide a zip file that you could deploy in a web server such as tomcat to demonstrate the behavior.  I have already provided the source code.
Project Member

Comment 5 by sheriffbot@chromium.org, Mar 28 2018

Cc: viswa.karala@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 6 by jdu...@juno.com, Mar 29 2018

The purpose of the code that broke is to...
1) check if chrome unsandboxed setting for our site is set to Allow, Ask, or Block
2) if not set to Allow, give a user ability to set to Allow so our feature can be enabled. 

If google can provide us an alternative we will switch to it. 

We tried the google content settings api via JavaScript and it seems to always return null.

Perhaps we are using this API incorrectly or that is intended for extensions only and as a site we should use something else. 

If Google can tell us an alternative that we can use to check the google permission and give user the google Allow banner to update the site setting then we can solve this problem ourselves.

Labels: TE-NeedsTriageHelp
Unable to test this issue from TE end, as per comment# 4 from reporter, as this issue needs to be tested by deploying the code in web server like tomcat to confirm the issue, hence adding the TE-NeedsTriageHelp label, could someone from the Dev team have a look at this issue.

Thanks!

Comment 8 by jdu...@juno.com, Apr 5 2018

Hello Chromium team - just checking back to see if you have made any progress on this issue.  We are still without a solution and need assistance.  Is there anything else we can provide you to move this along?

Comment 9 by ajha@chromium.org, Apr 5 2018

Cc: raymes@chromium.org
Cc'ing raymes@(chromium//src/third_party/adobe/OWNERS) for help in further investigation.
Cc: lafo...@chromium.org

Comment 11 by laforge@google.com, Apr 16 2018

Cc: jecl...@adobe.com smori...@adobe.com
Hey Satoshi/ Jeromie,

Based on the screenshots (see attached from comment #0), does this look like it could this be related to the recent worker lock down?

Comment 12 by jecl...@adobe.com, Apr 16 2018

Hey Anthony.  It's not related to workers.  The assets that need to be installed aren't getting downloaded.  I'm optimistic that we can solve this at the infrastructure level rather quickly.

Comment 13 by jdu...@juno.com, Apr 18 2018

Hello Chromium team - this latest post sounds like good news.  We are still looking for a solution to this problem, so we hope progress continues.

Comment 14 by jdu...@juno.com, Apr 30 2018

Hello Chromium team - we have heard reports that this issue is fixed.  Could you let us know if you or Adobe has done anything to fix this issue?

Comment 15 by jecl...@adobe.com, Apr 30 2018

We fixed this on our end.  Thanks!

Comment 16 by jdu...@juno.com, Apr 30 2018

Thank you Adobe.  We will be verifying the issue in the next day or so.

Sign in to add a comment