Skip to main content
L
lrkryptonic
Participant
August 29, 2013
Answered

File downloads not working in Pepper-Flash beta 11.8.800.115 (chrome)

  • August 29, 2013
  • 5 replies
  • 6792 views

Pepper-Flash Beta version 11.8.800.115 was auto-installed in latest Chrome update (29.0.1547.57 m).  This flash version does not display save/open dialog when clicking on a link that opens a file via flash.net.navigateToURL(request, "_self").  Request is an http get that calls a servlet that responds with a binary stream.

This topic has been closed for replies.
Correct answer jeromiec83223024

After careful investigation, it looks like the issue is related to a change in Chrome introduced in 29.0.1506.0 (build 199632).

We've opened the following Chromium Bug in response: 

http://code.google.com/p/chromium/issues/detail?id=282642&thanks=282642&ts=1377896509

I just wanted to thank everyone here for the positive tone and helpful workaround suggestions.  We'll continue to work with our counterparts at Google to get the issue resolved.

Thanks!

5 replies

A
adrbe
Participant
September 6, 2013

The problem seems to be related to the Content-Disposition header. When I remove the header, or use "inline" instead of "attachment", file download via navigateToURL (HTTP GET) works in chrome/pepper-flash. However, since the browser will attempt to open the file, content type becomes more important. For example, chrome won't properly open a pdf with a content type of "application/octet-stream". Most standard mime types (text, jpg, png) seem to open fine without specifying a content type, but pdfs do not.

This isn't ideal, since we prefer to force download, but we're checking the user-agent and only applying the logic to chrome 29.0.1547.*. Perhaps we should be applying to an earlier version of chrome. Can anyone confirm this problem exists in earlier versions, and if so what version? lrkryptonic and I first noticed it in version 29.0.1547.57.

Thanks to everyone for their input.

jeromiec83223024
jeromiec83223024
Inspiring
September 6, 2013

Our testing says that the change was first introduced in Chrome 29.0.1506.0

P
pteroo
Participating Frequently
October 2, 2013

Fixed today for me with the update Chrome 30.0.1599.66 (Mac)

P
pteroo
Participating Frequently
September 4, 2013

Temporary solution if your request is GET :

ExternalInterface.call("window.location.replace", url);

Where url is a String containing the path to your file.

Doesn't work with POST request because we can't make POST request with window.location.replace javascript function or other. But you can create and submit a form in a javascript function and then call this function with ExternalInterface.call

M
morri_javi
Known Participant
September 4, 2013

Same problem here. We were using this for years and now it isn't working only in Chrome with Pepper Flash.

This temporary solution seems to work, but we can't use it because we have a notification when you're trying to leave the page and it prompts when we do window.location.replace.

Hope it is solved soon, it freaked me out yesterday and I didn't know why it wasn't working.

P
pteroo
Participating Frequently
September 4, 2013

What if you try window.location.href ?

P
pteroo
Participating Frequently
August 30, 2013

Same issue here !

To reproduce, take this line of code :

navigateToURL(new URLRequest('http://a1408.g.akamai.net/5/1408/1388/2005110403/1a1a1ad948be278cff2d96046ad90768d848b41947aa1986/sample_iPod.m4v.zip'), '_self');

Expected :

Browser should display a save dialog to download file.

Works :

IE, Firefox, Safari, Chrome without PepperFlash

But :

In Chrome with flash player PepperFlash 11.8.800.115, it doesn't work.

Chrome make the request, and if the he cannot open the file (not png, txt, pdf...), he close the connection.

jeromiec83223024
jeromiec83223024
Inspiring
August 30, 2013

Thanks.  I created test media for the issue this morning and was able to reproduce it. 

I filed bug 3622211 to track this issue.

L
lrkryptonicAuthor
Participant
August 30, 2013

Thanks, Jeromie.  We have been testing workarounds that touch the content-type and content-disposition of the header, to be invoked only for Chrome user-agent.  Once we get a temp patch up and running in our production environment, we'll share details in the forum.

S
sysfor
Participant
August 30, 2013

I have the same issue here, except that I'm making a POST request via navigateToURL.

A new tab is opened, but it remains empty.

Working fine in FF & IE.

Sorry that I cannot provide access to the app since it handles confidential data.

sys

D
DJTTR
Participant
August 30, 2013

We are having the same issue with downloads no longer working in Chrome from a navigate to url call in Flash.  Both IE and Firefox work fine.  This just started happenning in Chrome pepper 11.8.800.115.  If one displays the Chrome developer tools window at the bottom of the Chrome browser, the http requests display with a status of "Cancelled".  If one disables the pepper version in Chrome and installs the regular 11.8.800.149 beta version, the download appears to work fine in Chrome.  Hope this helps resolve the issue, thanks

jeromiec83223024
jeromiec83223024
Inspiring
August 29, 2013

In most instances, we're just handing the network calls off to the browser and don't really have control over what happens.  Chrome has been doing a lot of hardening in the last couple releases as well. I'd need to do a bunch of differential testing to figure out what changed.

I'd be more than happy to investigate, but I'd be guessing at what your servlet is exactly doing.  I would be much faster and I'd have a higher chance of successfully figuring it out if I could get a link to a reproducible example.  You can send me a private message (just click my name) if you don't want to post it publicly. 

Thanks,

Jeromie Clark

Quality Engineering Manager - Flash Runtime Security

jeromiec83223024
jeromiec83223024Correct answer
Inspiring
September 5, 2013

After careful investigation, it looks like the issue is related to a change in Chrome introduced in 29.0.1506.0 (build 199632).

We've opened the following Chromium Bug in response: 

http://code.google.com/p/chromium/issues/detail?id=282642&thanks=282642&ts=1377896509

I just wanted to thank everyone here for the positive tone and helpful workaround suggestions.  We'll continue to work with our counterparts at Google to get the issue resolved.

Thanks!

L
lrkryptonicAuthor
Participant
September 6, 2013

Thank you for pursuing this issue and getting to the root of the problem.  I appreciate your efforts, Jeromie, and am keeping my fingers crossed for a speedy resolution.

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