Note that long pressing on images contained in webpages still works.

Actually the context menu from the the WKWebView seems disabled through the app. Long pressing on iframe also does not work.
Assigning to Eugene as it might be related to a change in web.

Since the WKWebview is supposed to show this menu, could the problem be caused by us using the new SDK?

Good version: 62.0.3195.0 #6806c55
Bad Version: 62.0.3196.0 #ee1e477

We should never show the iOS system context menu anymore because it can be very confusing. (This change was made here: https://chromium-review.googlesource.com/c/chromium/src/+/628576) However, it looks like when there is only an image and no webpage we were relying on the system context menu for the Save image and copy menu.

We should extend our context menu functionality to handle this case, but it may be non-trivial because our context menu detection returns details about a DOM element. I will test to see if we get any details about this image back.

Also, is this only an iOS 11 issue? I tried this on my iPhone 7 on iOS 10.3.3 in M61, M62, and M64 and can't reproduce the problem. The menu always shows when I'm viewing an image not contained in a webview.

Should we revert the change to never use the system context menu until we can get a reasonable solution for standalone images, or does that re-open a ton of other potentially confusing bugs and this is still a better situation?

I don't know how frequent this "feature" is used. Save Image still works from our implementation of the context menu, but is missing if the user is viewing a raw image.

My preference would be to update our own context menu to display in this scenario rather than revert the CL. I don't yet know how complex of a change this will be as Safari inspector isn't working with my iOS 11 simulators. Once I have more details or a potential fix, I will share them here.

Our context menu is blocked on an image only page because we don't inject the windowID. This causes the context menu getElementAtPoint JS to fail the windowID check.

eugenebut@, instead of testing for html in crw_web_controller |contentIsHTML|, WDYT about excluding the PDF mime type that was causing the previous DCHECK instead?

Ref: https://codereview.chromium.org/2542303002

michaeldo@ if injecting window ID into a page with an image is possible, then solution form comment #11 sounds good to me.

It is possible with an image.

I can't reproduce the previous DCHECK with pdfs though. I can inject into a pdf on ios10 and 11 without issue. Do you recall how to reproduce that problem more specifically so that I don't cause a regression?

I think DCHECK was firing on loading PDF file. It could be iOS 9 or early iOS 10 problem, which is now fixed. It's ok to remove contentIsHTML check if you don't see DCHECK on the bots.

michaeldo@ do we have any update here?

I am making a change to always inject the windowID. This will fix the missing context menu by showing our custom context menu on the page. (This will look different than the Save/Copy menu that was shown before. It will match the menu shown when long pressing an image on a web page.)

If the bots reveal any DCHECKs, we would need to inject only if the mime type is not pdf.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c47b1f13138b9f12b01da22ab11a82a8cf639bcc

commit c47b1f13138b9f12b01da22ab11a82a8cf639bcc
Author: Mike Dougherty <michaeldo@chromium.org>
Date: Tue Oct 24 18:34:43 2017

Inject windowID when web view content is an image.

The system context menu is now always blocked, so we must use our own
to allow interaction with image content. We must inject the windowID
because our context menu implementation relies on injected javascript.

Bug:  777313 
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: I0c0c5515c3fe99e5f7db6d963c0cdc1ec84940ac
Reviewed-on: https://chromium-review.googlesource.com/735121
Commit-Queue: Mike Dougherty <michaeldo@chromium.org>
Reviewed-by: Eugene But <eugenebut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#511214}
[modify] https://crrev.com/c47b1f13138b9f12b01da22ab11a82a8cf639bcc/ios/web/web_state/ui/crw_web_controller.mm

Always injecting the windowID fails if the mime type is html/plain, so I added a check to explicitly inject the windowID if the mime type starts with "image".

[Auto-generated comment by a script] We noticed that this issue is targeted for M-62; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-62 label, otherwise remove Merge-TBD label. Thanks.

It was decided that the fix will not be included into M62. Estelle, please confirm.

Your change meets the bar and is auto-approved for M63. Please go ahead and merge the CL to branch 3239 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

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

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e49f6489e73639e670cd96bde5aa7525da61ddb2

commit e49f6489e73639e670cd96bde5aa7525da61ddb2
Author: Mike Dougherty <michaeldo@chromium.org>
Date: Fri Oct 27 15:59:35 2017

Inject windowID when web view content is an image.

The system context menu is now always blocked, so we must use our own
to allow interaction with image content. We must inject the windowID
because our context menu implementation relies on injected javascript.

Bug:  777313 
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: I0c0c5515c3fe99e5f7db6d963c0cdc1ec84940ac
Reviewed-on: https://chromium-review.googlesource.com/735121
Commit-Queue: Mike Dougherty <michaeldo@chromium.org>
Reviewed-by: Eugene But <eugenebut@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#511214}(cherry picked from commit c47b1f13138b9f12b01da22ab11a82a8cf639bcc)
Reviewed-on: https://chromium-review.googlesource.com/740946
Reviewed-by: Mike Dougherty <michaeldo@chromium.org>
Cr-Commit-Position: refs/branch-heads/3239@{#264}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/e49f6489e73639e670cd96bde5aa7525da61ddb2/ios/web/web_state/ui/crw_web_controller.mm

Verified on 64.0.3254.0 canary on iPhone 8(iOS 11.0), iPhone 6s plus(iOS 10.3.3) and iPad Air(iOS 11.2)

Followed the steps mentioned in comment#0, on long press the context menu is displayed with save image menu item

Verified on 63.0.3239.27 Beta on iPhone 8(iOS 11.0), iPhone 6s plus(iOS 10.3.3) and iPad Air(iOS 11.2)

Followed the steps mentioned in comment#0, on long press the context menu is displayed with save image menu item

 Issue 780082  has been merged into this issue.

Is it possible to add automated regression test coverage for this? Michaeldo@ can you please check what's feasible?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fafb106221368b1fc96c49909c1822e8662935f5

commit fafb106221368b1fc96c49909c1822e8662935f5
Author: Mike Dougherty <michaeldo@chromium.org>
Date: Fri Dec 01 05:35:28 2017

Add test to ensure context menu triggers on image urls.

Expose GetActiveViewController from chrome_test_util.

Bug:  777313 
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: Ib819e24af2abb9f49ce6a4e44114142ba8d0ce42
Reviewed-on: https://chromium-review.googlesource.com/795095
Commit-Queue: Mike Dougherty <michaeldo@chromium.org>
Reviewed-by: Mark Cogan <marq@chromium.org>
Cr-Commit-Position: refs/heads/master@{#520861}
[modify] https://crrev.com/fafb106221368b1fc96c49909c1822e8662935f5/ios/chrome/browser/context_menu/context_menu_egtest.mm
[modify] https://crrev.com/fafb106221368b1fc96c49909c1822e8662935f5/ios/chrome/browser/ui/safe_mode/BUILD.gn
[modify] https://crrev.com/fafb106221368b1fc96c49909c1822e8662935f5/ios/chrome/browser/ui/safe_mode/safe_mode_egtest.mm
[modify] https://crrev.com/fafb106221368b1fc96c49909c1822e8662935f5/ios/chrome/test/app/chrome_test_util.h
[modify] https://crrev.com/fafb106221368b1fc96c49909c1822e8662935f5/ios/chrome/test/app/chrome_test_util.mm

Thank you!

 Issue 789829  has been merged into this issue.

lindsayw@, no problem! Regression test has been added to context_menu_egtest, "testContextMenuDisplayedOnImage"

The image no context menu problem is still failing for some users/sites.  See follow on Issue 794206, opened 12/12/17.

For example: the Help Forum:
https://productforums.google.com/forum/#!topic/chrome/9WhtBd0t0n8