Are we still doing this?

If this is low effort (i.e. using some API provided by WKWV) then I have no objections to it. I don't think it's high priority or will get a lot of usage. 
iGSA is planning to implement peek and pop for the Now Cards. Would be interesting to know if they get used (albeit a different use case than simple links)

I think M55 is too ambitious if we still need a round of UX work. 

I've created a design doc here: go/wkwebview-link-preview

I'm not sure how elaborate the UI Pete is interested in pursuing here, but the actual integration that I did for the hackathon was pretty straightforward, so we should be able to move relatively quickly once we hammer out some functionality details.

Just seen this: https://webkit.org/blog/7016/ios-10-link-preview-api-in-wkwebview/

Seems like we can provide a custom view controller to see the link, but I wonder if we can really show it as a tab.

Adding marq for future thinking related to the new Bling clean skeleton.

I'd like to propose that we try to keep this as simple as possible and as close to safari's UX as possible. That'll keep the churn with UX to a minimum. We can always do more in followup versions, but I don't want that to be the long pole on decision-making.

I would also like to keep the initial implementation minimal, but enabling the link preview without providing a custom UIViewController will open previewed links in the Safari app rather than adding to the session history within Chrome.

That being said, I did a quick version of this during the hackathon a while back that worked fine, although there was no URL displayed during the preview animation.  Additionally, when the previewed navigation was committed, the animation was slightly jarring, as there was not a smooth transition from the preview UIViewController to the regular Chrome UI with the toolbar.

This issue shows up consistently in users feedback too (see attachments). 
Kurt: Is there no easy way to smoothen that jarring transition?

Deleted: Screen Shot 2017-02-13 at 15.31.29.png 30.0 KB

	Screen Shot 2017-02-13 at 15.31.29.png 30.0 KB View Download

Deleted: Screen Shot 2017-02-13 at 15.31.48.png 44.4 KB

	Screen Shot 2017-02-13 at 15.31.48.png 44.4 KB View Download

Deleted: Screen Shot 2017-02-13 at 15.31.59.png 46.3 KB

	Screen Shot 2017-02-13 at 15.31.59.png 46.3 KB View Download

Deleted: Screen Shot 2017-02-13 at 15.32.16.png 27.4 KB

	Screen Shot 2017-02-13 at 15.32.16.png 27.4 KB View Download

I think a janky animation is probably better than none at all, but I'd like to see a movie capture of what the hackathon version looks like. 

I've uploaded the video from the hackathon.  It's actually not as bad as I remember; we could probably ship this animation as a first implementation.

https://drive.google.com/open?id=0B59HnUenJr6vaWFuSGQ0VE1LWkk

Cool. Thanks, Kurt! I agree that this is not so bad and would definitely cause users delight. I'd probably need to play with it on canary. How difficult is it to put it behind a flag? 

I don't have the code on my computer anymore, but I remember it only taking an afternoon to implement the first time around.  I'll try to get it in sometime this week so you can play around with it on canary.

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

commit ab748439edfaec67875bcaf8dde1d9726c896f05
Author: Hiroshi Ichikawa <ichikawa@chromium.org>
Date: Thu Sep 21 07:46:28 2017

Add Peek&Pop delegates to WebStateDelegate and CWVUIDelegate.

Change-Id: I4ba0e14f4a8466ece6effeec7eab3aa0484e4ebd

Bug: 643318
Change-Id: I4ba0e14f4a8466ece6effeec7eab3aa0484e4ebd
Reviewed-on: https://chromium-review.googlesource.com/651673
Reviewed-by: Eugene But <eugenebut@chromium.org>
Commit-Queue: Hiroshi Ichikawa <ichikawa@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503383}
[modify] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web/public/test/crw_mock_web_state_delegate.h
[modify] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web/public/test/crw_mock_web_state_delegate.mm
[modify] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web/public/test/fakes/test_web_state_delegate.h
[modify] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web/public/test/fakes/test_web_state_delegate.mm
[modify] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web/public/web_state/web_state_delegate.h
[modify] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web/public/web_state/web_state_delegate_bridge.h
[modify] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web/web_state/ui/crw_web_controller.mm
[modify] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web/web_state/web_state_delegate.mm
[modify] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web/web_state/web_state_delegate_bridge.mm
[modify] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web/web_state/web_state_delegate_bridge_unittest.mm
[modify] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web/web_state/web_state_impl.h
[modify] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web/web_state/web_state_impl.mm
[modify] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web/web_state/web_state_impl_unittest.mm
[modify] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web/web_state/web_view_internal_creation_util.mm
[modify] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web_view/BUILD.gn
[add] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web_view/internal/cwv_preview_element_info.mm
[add] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web_view/internal/cwv_preview_element_info_internal.h
[add] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web_view/internal/cwv_preview_element_info_unittest.mm
[modify] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web_view/internal/cwv_web_view.mm
[modify] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web_view/public/ChromeWebView.h
[add] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web_view/public/cwv_preview_element_info.h
[modify] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web_view/public/cwv_ui_delegate.h
[modify] https://crrev.com/ab748439edfaec67875bcaf8dde1d9726c896f05/ios/web_view/shell/shell_view_controller.m

ios/web part of the implementation was landed.

(Moving conversation from email thread to this issue for visibility.)

1) UX will provide instructions/specs for peek view
2) We need to decide what the pop action should be (i.e. what happens when continuing to push after the peek view has appeared). I see two reasonable options to consider:
2.a) Open link in a new tab (Kurt's in-flight CLs do this)
2.b) Commit a navigation in the current tab (Safari does this)

Kurt mentioned the following about 2.b: "We'd lose the WKBackForwardList with [2.b], so some navigations will be affected after committing the navigation (i.e. POST requests, some history state operations)." Not sure I completely grok the implications there or how it would feel when a navigation is "lost", but I personally think 2.b is the right way to go because:
- expectations have been set by Safari
- this feels like an extension of the long-press link gesture

3) We need to decide what contextual actions to expose when swiping the peek view up. 
 Kurt mentioned using the same long-press link actions, and I agree. So: "Open in New Tab", "Open in New Incognito Tab", "Read Later" and "Copy Link URL". (This list would obviously be impacted by the decision made for 2.)