hongchichang@ are they reporting more information about this? Could we probably ask them for more info? Its going to be hard to fix without it.

Just wanted to add here that testers went through the user reports bucket for this and none of the reports for M63 are reproducible. 

Thank you Lindsay for the update. I agree this is hard to do anything about without more details. The only place I can think of this being an issue is within a cross-origin iframe, which would not be the case if you are directly looking at an image. (Ex: https://domain.com/image.jpg)

Here are some feedback reports:
When you go to the report, you can click "PII" on the top-right corner of the report to see the URL. 

Feedback #1: I can reproduce this
https://listnr.corp.google.com/report/84766760042
"In all cases it works fine, except when I clicked download button in unsplash.com. This button redirects us to another blank page with original size of image and in that page holding pressed gives us no result. Same link works fine with other browsers (Safari mobile)."

Feedback #2:
https://listnr.corp.google.com/report/84783923559

Feedback #3:
https://listnr.corp.google.com/report/84775126618

Feedback #4: I can not reproduce this and reached out to user for more information
https://listnr.corp.google.com/report/84784122103

Thank you for the details. I started investigating with the first link and found that we fail to inject javascript into the new tab that opens when trying to download an image from unsplash.com.

The script injection fails with WKErrorDomain WKErrorJavaScriptExceptionOccurred.

I connected Safari Web Inspector and I see the following error in the console:
Blocked script execution in 'https://images.unsplash.com/photo-1512927638316-b12f8c1abcc4?ixlib=rb-0.3.5&q=85&fm=jpg&crop=entropy&cs=srgb&dl=joe-green-475962.jpg&s=98076fe927527257b04e9065a9ac892f' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.

Also, I'm wondering if this is limited to iOS 11? I CAN actually get the "Save Image" action sheet to display on my iPhone 7 on iOS 10.3.3.

Feedback #2 and #3 seem to be trying to access content which may explicitly trying to prevent the user from saving the data.

I can confirm that we can't add our scripts to the unsplash.com download page with the error from the inspector in comment #6. I believe this is a new problem in iOS 11.

The only difference I can discern from the responses (vs a working raw image), is that in the failure case the content to returned as a "Download" rather than a direct raw image. A header of this form exists in the failure case:

   Content-Disposition: attachment; filename="filename.jpg"

We may need to test a simplified case to ensure this is the root of the problem, but it looks like we can't inject scripts to such downloads anymore.

In order to fix this, we probably need to present the image from our own html page (or maybe native download page?). Alternatively, we may be able to directly support the "save" context menu action if we know that the rendered content is a raw file instead of trying to fetch the image url from the DOM.

eugenebut@ WDYT?

Content-Disposition: attachment; filename="filename.jpg" responses should be handled as Downloads ( crbug.com/574033 ). Do you think this is a dup of  crbug.com/574033 ?

It's just not clear to me what users mean by "Safe"? "Save the image via context menu" or "Download the image via Download Manager".

Mike can you file a separate bug to investigate why the scripts were not injected. Chrome for iOS looses bunch of features without scripts injections.

I do believe they mean "via context menu" based on my experience reproducing the issue.

I dont think we expect download manager for image because we render the response in the webView if the WKNavigationResponse returns true from canShowMIMEType.

https://cs.chromium.org/chromium/src/ios/web/web_state/ui/crw_web_controller.mm?rcl=762d8538528b19ad970a2fc525ca1252c6d1c863&l=4285

I will file a separate bug regarding js injection failure.

Does this still need to be labeled "Needs-feedback"?

The bug does not have steps to reproduce, so Needs-feedback seems like appropriate label to me.

It depends on how the image is opened in the new tab. I believe a user (Alessio) has isolated the use case here:
https://productforums.google.com/forum/#!topic/chrome/9WhtBd0t0n8
https://productforums.google.com/d/msg/chrome/9WhtBd0t0n8/pLRNdqysBAAJ
See his 3/14 1:56a (PST) comment: target _blank has no context menu.

More later..

iOS user Alessio reports 3/14 in https://productforums.google.com/d/msg/chrome/9WhtBd0t0n8/4kUodoraBAAJ
for Chrome 65, iOS 11.2.6 for both his iPhone and iOS tablet:

A link to test this bug is: https://wallpapersite.com/movies/black-panther-hd-5k-12019.html , Just tap on one of the links that show the desired resolution to open the image.

and..
the bug occurs only in case [when] the site opens the image with a target "_blank" because if I try to take the image in a new tab by myself the image can be saved without problems but if the site open the image for me in a new tab in this case the image is impossible to save [no long press context menu].

For the test page:
  https://wallpapersite.com/movies/black-panther-hd-5k-12019.html
the target="_blank" can be seen be inspecting the anchor elements for the image links, see attached screenshot.

The user (Alessio) reports only image link with the target="_blank" parm fail to have the long-press context menu.

The DevTools screenshot is from a Windows Desktop.  We're assuming iOS would show the same HTML.

Although in Italy (+9H WRT PST), Alessio has been responsive and understands the console.  If someone can pick this up soon, he may be available to troubleshoot.  See the help forum link above.

Deleted: Alessio-IOS_BLANK_TARGET_dt-i316.png 797 KB

	Alessio-IOS_BLANK_TARGET_dt-i316.png 797 KB View Download

iOS 11.2.6 and Chrome 65 have the same bug as Chrome 63 for iOS

Yes, confirm that every site that refers to an image through target "_blank" in a new tab does not allow the saving of the image. 
a new example can be seen on the hdqwall site (as in attached image).

Deleted: anothersite_samebug.png 353 KB

	anothersite_samebug.png 353 KB View Download

The link for Alex's c#17 example is
   https://hdqwalls.com/avengers-infinity-war-official-poster-2018-wallpaper

I am unable to reproduce on 65.0.3325.152 (current stable release from App Store) and iOS 11.2.6. Please see attached screenshot.

I tested by clicking the Original Resolution link from the URL in comment #17. Then long pressed on the image in the new tab. (Am I missing a step to be able to reproduce?)

Deleted: IMG-8739.JPG 1.7 MB

	IMG-8739.JPG 1.7 MB View Download

michaeldo@ - Try also the link in c#14. For the c#14 black panther download, he selected one of the target device resolutions.

In the past Alex has responded around 9p PST.

I'll copy your comment to the forum thread 
https://productforums.google.com/forum/#!topic/chrome/9WhtBd0t0n8

I verified that I can reproduce the issue in c#14 and it is the same problem as I described in comments #6 and #7. Javascript execution is blocked on the page according to an error printed to the web console.

We rely on WKWebView to render the image which is causing the injected JavaScript to not be callable from the native application side. I will check if I filed a Radar for this case and file one if I haven't already.

I've filed a radar for this issue:
https://bugreport.apple.com/web/?problemID=39012096

Does this problem inly apply to JPEG images? If I remember correctly for some images we could execute JavaScript.

This doesn't apply to all JPEG images, only if the image was meant to be a "download" and includes a header like this:
    Content-Disposition: attachment; filename="filename.jpg

If you use the Context Menu to "Open Image", the context menu will work in those cases.

I've tried to use Download Manager for responses which use Content-Disposition: attachment and I'm not sure if I liked the user experience. Mike, do you think we could update OpenInController to support images as well?

I agree that Download Manager probably isn't the best option. I like the OpenInController solution, it would certainly be an improvement over the current behavior where the image can only be viewed. I was able to very quickly try this and it works to show the image and Open In menu.

I did notice that there is no Copy option, but I can debug that further if we decide to go this route.

mardini@, Context Menu doesn't display in these cases. WDYT about using OpenInController (see example attached) to help users be able to do something if the website sends the image as a "download"? Note that the screenshots are from simulator, so there are not many options, but more exist on the device.

Deleted: Screen Shot 2018-04-05 at 11.47.15 AM.png 2.1 MB

	Screen Shot 2018-04-05 at 11.47.15 AM.png 2.1 MB View Download

Deleted: Screen Shot 2018-04-05 at 11.47.25 AM.png 930 KB

	Screen Shot 2018-04-05 at 11.47.25 AM.png 930 KB View Download

SGTM. Thanks.

I looked into this and uploaded a CL (crrev.com/c/1162690) for adding support to OpenInController for images.

However, I came across these two bugs below which I believe should be fixed before expanding the use of OpenInController to images.

 crbug.com/862596 
The loading UI for "Open In" is currently not being displayed. (Without this fix, there is no UI after the user taps on Open In to indicate that the content is being downloaded.)

crbug.com/625616
Open In toolbar is not displayed on images with my prototype CL. I don't know if this bug is the only root cause or if there is more work that needs to be done in order for the bar to display properly.

Thanks, Michael. I agree that  issue 862596  needs to be fixed. Is there someone working on it?

As for issue 625616, does that happen only if the new tab is opened from the Today View?

Mardini, no one is actively working on  crbug.com/862596 , which blocks this bug. 

Regarding issue 625616, no it is not just related to Today View. The bar is not displaying on top of any image. It is likely due to the way the bar is being presented, but it could be some other cause.

Thanks. Who is the best person to own this and get it across the finish line? 

Peter or Eric should be able to answer question #33.

OK. Let's ping this bug again on Monday when Eric is back

The NextAction date has arrived: 2018-08-27

Peter, Eric, do we have anyone to add Open In... support for images?

I'm confused by this bug. The server returns a clear message that the content should be downloaded, not displayed. Isn't what the download manager is for? Why not sending it directly there, without displaying it first? 

Re to Comment 38: It is possible to honor "Content-Disposition: attachment" header and we even considered this option ( crbug.com/574033 , https://crrev.com/c/988262). However the user experience of downloading the image is pretty bad. First of all, the user has to tap "Download" and then "Open In...". After that the user has to pick a sharing extension and then open an image in a different app. It's just too much friction for the user and I think we should only use Download Manager for files which can not be displayed in web contents area. FWIW, Chrome for Android does not honor "Content-Disposition: attachment" header.