Chrome Version: 59.0.3050.0 (Developer Build) (64-bit)
OS: Mac OSX
What steps will reproduce the problem?(1) Navigate to about:blank and open devtools.
(2) Edit page to the following:
<input value="crash"/>
<script>
document.querySelector('input').onfocus = function() {
setTimeout(function() {
this.selectionStart = 0;
this.selectionEnd = this.selectionStart;
}.bind(this), 1000);
}
(3) Click into the <input> and wait until selection clears. The select LookUp from
context menu.
What is the expected result?
It should either show the dictionary for 'crash' (the word in context menu), show dictionary for empty string (since we have lost selection), or just do nothing.
What happens instead?
DCHECK fires.
For graphics-related bugs, please copy/paste the contents of the about:gpupage at the end of this report.
Chrome Version: 59.0.3050.0 (Developer Build) (64-bit)
OS: Mac OSX
What steps will reproduce the problem?
(1) Navigate to about:blank and open devtools.
(2) Edit page to the following:
<input value="crash"/>
<script>
document.querySelector('input').onfocus = function() {
setTimeout(function() {
this.selectionStart = 0;
this.selectionEnd = this.selectionStart;
}.bind(this), 1000);
}
</script>
(3) Click into the <input> and wait until selection clears. The select LookUp from
context menu.
What is the expected result?
It should either show the dictionary for 'crash' (the word in context menu), show dictionary for empty string (since we have lost selection), or just do nothing.
What happens instead?
DCHECK fires.
For graphics-related bugs, please copy/paste the contents of the about:gpu
page at the end of this report.
Chrome Version: 59.0.3050.0 (Developer Build) (64-bit)
OS: Mac OSX
What steps will reproduce the problem?
(1) Navigate to about:blank and open devtools.
(2) Edit page to the following:
<input value="crash"/>
<script>
document.querySelector('input').onfocus = function() {
setTimeout(function() {
this.selectionStart = 0;
this.selectionEnd = this.selectionStart;
}.bind(this), 1000);
}
</script>
(3) Click into the <input> and wait until selection clears. The select LookUp from
context menu.
What is the expected result?
It should either show the dictionary for 'crash' (the word in context menu), show dictionary for empty string (since we have lost selection), or just do nothing.
What happens instead?
DCHECK fires.
This bug is due to my recent refactoring attempt here:
https://codereview.chromium.org/2694543002/
Which happens because in showLookupDictionaryOverlayInternal we might want to see if there is selected_text_. We not get it from the focused view which is obtained from RWHImpl::GetView() and that is a WeakPtr. Since the showLookup... is called from another thread (IO?) this issue happens. I will put up a CL for this and see how it looks.
(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}
Comment 1 by ekaramad@chromium.org
, Apr 4 2017