Can you provide screenshots showing the expected and actual behaviors?

Attached are two gifs, one the actual behavior from a <webview>, the other the expected behavior from.

Please let me know if they aren't clear or need to capture more.

Deleted: webview-lookup-definition-actual-behavior.gif 99 KB

	webview-lookup-definition-actual-behavior.gif 99 KB View Download

Deleted: webview-lookup-definition-expected-behavior.gif 117 KB

	webview-lookup-definition-expected-behavior.gif 117 KB View Download

Thank you for providing more feedback. Adding requester "erikchen@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

kevinsawicki@: Could you please elaborate more on the extension and navigating to the page having hello world, to triage from Test engg team.

I've uploaded the full extension to https://github.com/kevinsawicki/webview-show-definition-extension which has the manifest and main.js file being used.

I'm launching it by going to chrome://extensions and clicking the Launch link for it.

Thank you for providing more feedback. Adding requester "durga.behera@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Full repro steps (thanks for the info & gifs!):

1. On macOS, Navigate to https://github.com/kevinsawicki/webview-show-definition-extension
2. Click "Clone or Download" -> "Download as Zip"
3. Open the download in Finder to extract the contents of the zip into a new folder.
4. Navigate to chrome:extensions
5. Check "Developer Mode" checkbox at the top
6. Click "Load unpacked extension..." and navigate to the folder that was created in step 3.
7. A new extension should appear. Click "Launch".
8. Double-click on the word "Hello" to highlight, right click and click "Look up "Hello"".

Able to reproduce the issue on Mac 10.12.4 with chrome stable # 57.0.2987.133  and Canary # 59.0.3061.0 as steps mentioned in the comment #9.
Issue is broken in M56

Bisect Info:
===============
Good build : 56.0.2894.0 ,  Revision Range - 425838
Bad build  : 56.0.2895.0 ,  Revision Range - 426105

After executing the per-revision bisect script , i got the following CL's between good and bad build versions
===========================================
https://chromium.googlesource.com/chromium/src/+log/6d56ffd26c3994cd498aef31bedbcb86d17f2434..3f7daa9733a4d5d3c06359b9f92c3bde20c7dd5d

The suspecting Change Log is :
==============================
https://chromium.googlesource.com/chromium/src/+/3f7daa9733a4d5d3c06359b9f92c3bde20c7dd5d

Review-Url: https://codereview.chromium.org/2382003002

Note: Issue is not testable in Windows 10 and Ubuntu 14.04, since on right clicking there is no look up option. 

ekaramad@- Could you please look into this issue, if it's related to your change?  if not could you please help us to reassign this issue to the right owner.

On 56 this does not even popup the dictionary for me. On 59, doing it twice on the same word works. I will look into this.

Friendly ping!
ekaramad@,
Still we are able to reproduce the issue on latest Canary-59.0.3068.1.Could you please check and update the issue accordingly.
Thank you.     

Sorry for the delay in updating the bug. I have been working on higher priority issues. I will try to find a fix for this soon. Thanks!

I have a CL which is under review. This will fix the issue and some other dictionary related issues:
https://codereview.chromium.org/2817673003/

(The fix has landed but somehow not posted to this bug):

The following revision refers to this bug:
commit 67a361af4485aee793aa2ad8dacddd249d19fc1c
Author: ekaramad <ekaramad@chromium.org>
Date:   Tue Apr 25 15:45:38 2017 -0700

Making Mac Dictionary better for OOPIFs and <webview>
    
There is two ways to invoke Mac dictionary for Chromium: choosing look-up word
in context menu for highlighted text, or pressing Ctrl + Command + D. Both methods
might involve sending an IPC through TextInputClientMac to the RenderWidget
corresponding to the string (i.e., focused RenderWidget or the RenderWidget at
the position of mouse cursor). In both cases the IPC comes back with a string
and a position with respect to the local roots view port coordinates. The result
however is handled on IO thread which leads to complications such as a DCHECK
firing (at times) due to accessing the RenderWidgetHostViews weak pointer when
getting the focused RenderWidgetHost.

Furthermore, word lookup through context menu is broken for <webview>s; both
OOPIF-based and BrowserPlugin-based. The former type of <webview>s don't
support this feature because RenderWidgetHostViewChildFrame does not implement
ShowDefinitionForSelection() method. The latter have regressed after implementing
Mac dictionary support for OOPIFs () where the IPC for getting the string from
range is only sent to a RenderWidgetHost which is part of the frame tree (which
will not be that of a guest represented by a BrowserPlugin).

This CL will:

1) Handle dictionary related IPCs on the UI thread to remove the threading issue
and make transforming the reported points to root coordinates based on compositor
frames and the right OOPIF way (calling RWHV::TransformPointToRooTCoordSpace which
can only be done on the UI thread).

2) Implement RenderWidgetHostViewChildFrame::ShowDefinitionForSelection().
3) Make sure that for BrowserPlugin-based guest the IPC is sent to the
RenderWidget of the guest renderer.

The CL also adds a test to avoid regressions in word lookup inside guests.

TBR=shuchen@chromium.org
BUG=643233,  702348 ,  708183 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2817673003
Cr-Commit-Position: refs/heads/master@{#467149}

I verified the fix. Do we need to merge this fix into 59 (it is a regression since 56)?