Unable to reproduce this issue on reported version 62.0.3202.94 and on latest canary 65.0.3285.0 using windows 10 and Mac 10.13.1 using steps mentioned below. Attaching screencast for reference.

1. Launched chrome and navigated to chrome://settings.
2. Changed Advanced->Content Settings->Flash to "Ask First".
3. Navigated to http://www.hbo.com//bin//hboPlayer.swf?vid=1086687 and observed no download of flash content. Instead 404 page is seen.

@Reporter: Could you please check the video and let us know if we miss anything. And also please provide us alternate URL to check this as 404 page is seen. This would help in further triaging of the issue.

Thanks!

Hello :)

Thanks for checking into this so quickly :) I made a mistake, hbo uses a regional ip based system to filter access, so not the best example :)

Please try either of these from the google network for the poc:

https://ipv4.google.com/a/help/intl/ar/admins/resources/flash/apps_setup.swf

https://static.googleusercontent.com/media/ipv4.google.com/en//a/help/intl/ar/admins/resources/flash/apps_setup.swf

I've attached a capture here showing the behaviour:

https://www.dropbox.com/s/7r0clvv1vzttazd/google_swf_download_poc.gif?dl=0

Wish you well on your side of the screen :)

-Eric 

Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

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

The option to set Flash to "Ask First" in chrome://settings->Advanced->Content Settings is introduced in M-62 milestone and from then the issue is seen.
This is a non-regression issue.
Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

This issue was already somewhat confusingly brought up here:

https://bugs.chromium.org/p/chromium/issues/detail?id=767342

I have two identical copies of Chrome, current ver., one that can execute a link like:

http://www.hbo.com//bin//hboPlayer.swf?vid=1086687

and the second where it attempts to download it instead.


The browsers are 100% identical by the "current" settings options.  The difference is in what settings were set in PREVIOUS versions, and are no longer available.  The settings have been "LOCKED" in as the option to change them has been removed.


Eric is 100% correct here, and the manual editing of settings file makes sense as a workaround, since it is settings that can no longer be changed that are preventing the direct running of swf links with URL option arguments.

You will note in the other closed out thread, and other places discussing this disastrous oversight, that in particular Educational Software that needs rich content (FLASH) that HTML5 is incapable of supporting, that pass data (URL arguments), that Chrome needs to take this issue seriously as it follows its roadmap for removal of Flash.

Many companies are preparing for 01/01/2021 and the end of Flash, but Chrome is bringing that day forward to NOW, by not properly testing their roadmap against all real world use cases of Flash.

Re-iterating to make perfectly clear:
======================================

Any direct link to an .swf with URL arguments, CANNOT be run on the current version of Chrome.

The Ask First, Per-Site permissions, etc, stuff that is currently available DOES NOT WORK if there are URL arguments:

ie:     example.swf?arg=1

The above .swf example CANNOT be run on a clean install of Chrome.  No option that exists in current version can make it function, period.  Only upgraded copies of the current version, where old settings no longer available persist, can have it run properly.

This is the problem in its most precise form.

What needs to be done, IMO:
1. Completely remove this hidden setting to always run Flash
2. If Flash is set to "Ask first" when navigating to a .swf URL, then ASK, do NOT download!
3. If the site is whitelisted, then run the .swf as usual. If the site is blacklisted or Flash is blocked, THEN (possibly) download.

It seems obvious the devs on this are just not going to acknowledge they screwed up because the number of users affected is small.

For those being dis-serviced by this, I suggest this solution if you are able to implement it:
============================================================

1.) Take your broken-by-chrome flash file:
http://broken-by-chrome.com/myGreatFile.swf?some=1&var=2

and convert it into a page that can rewrite the broken-by-chrome flashVars into a dynamically written Object/Embed style tag.

ie:
http://broken-by-chrome.com/FixWhatTheyDid.php?some=1&var=2


2.) Inside the "FixWhatTheyDid.php", grab the URL variables ($_GET array) and WRITE them into the Embed Tag as the FlashVARS property.

-------------------------------------
<?php
    $fieldnames_actual = array();
    $values = array();

    foreach($_GET as $k=>$v){
        if($k!='fieldnames'){
            $fieldnames_actual[] = $k;
            $values[] = $v;
            $flashArray[$k]=$v;
            if($flashVarString==""){
                $flashVarString=$k."=".$v;
            }
            else{
                $flashVarString.="&".$k."=".$v;
            }
        }
    }  
?>

<html something something>
<some more somethings>
<flash embed comes next>
<object>
   <param ...>
   <param ...>
   <param etc>
   <param name=FlashVars value="<?php echo $flashVarString; ?>" /> 
   <param ...>
   <embed src="myGreatFile.swf" otherArguments...>
</object>

-------------------------------------------------------



This should allow you to fix what Chrome broke, by only changing the targeted .swf, and if you CANT change that, you can still do what I said above, and create a "redirect" on your server, that will catch and repoint it from the targeted .swf to your "catch" file which can then load as shown above.

This will bypass Chrome's screw up.

There's over 50 stars on this duplicate that got swept under the rug:
https://bugs.chromium.org/p/chromium/issues/detail?id=767342

Would like someone to fix this. I need flash to run in my browser.

Yes, the behavior is wrong, but I think they're just going to run out the clock on this one until Flash is removed.

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time.
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Wednesday, 12/12/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

Due to lack of action this bug has been Archived. If work is still being done on this issue or you are still experiencing this issue please feel free to re-open with the appropriate information.