Unable to enter CJK & complex script on Google docs/presentation |
||||||||||||
Issue descriptionChrome Version : 59.0.3071.8 Platform : 9460.1.0 - pi URLs (if applicable) : docs.google.com What steps will reproduce the problem? (1) open Google document or presentation (2) set IME to Korean (3) enter "gksrmf",한글, on Title field (4) enter "gksrmf" on doc's body area What is the expected result? On step#4, user should be able to enter Korean What happens instead? Step#3, able to input Korean characters on title field Step#4, unable to enter Korean. Please provide any additional information below. Attach a screenshot if possible. Able to enter CJK/Complex script on Google Spreadsheets on chrome59.0.3071.8/CrOS 9460.1.0 - Pi. Able to enter CJK/Complex script on Document/presentation on chrome 59.0.3064.0/CrOS 9438.0.0 -Peppy
,
Apr 18 2017
For win7, please using the following steps : 1. add "Korean(Microsoft IME)" from Control Panel => Region and Language => Change Keyboards => General 2. Open Google document or presentation 3. move the mouse cursor on Title field 4. Switch IME to Korean/MicrosoftIME 가Han/Eng 5. enter ""gksrmf", then able to see "한글" 6. move the mouse cursor on body field 7. check the Korean IME What is the expected result? On step#7, the IME should be "Korean/MicrosoftIME 가Han/Eng". What happens instead? Step#7, The Korean IME is switched to "Korean/MicrosoftIME AHan/Eng..". And, unable to set IME to "Korean/MicrosoftIME 가Han/Eng"
,
Apr 18 2017
Not able to reproduce the issue on 59.0.3067.6/ Win7 Able to reproduce the issue on 59.0.3071.9/ Win7
,
Apr 18 2017
On Mac/Chrome 59.0.3071.9, I'm able to input only Korean alphabets on document's body area. Unable to composite alphabets. Steps to reproduce the issue: 1) open Google document 2) set IME to Korean and enter "gksrmf" on the document's body area What is the expected result? "한글" should be entered. What happens instead? "ㅎ ㅏ ㄴ ㄱ ㅡ ㄹ" is entered
,
Apr 19 2017
Bisect range : You are probably looking for a change made after 463574 (known good), but no lat er than 463575 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/68130af4b73ed4f2b62abb4d74b5da59a3854ea1..e14aacd2baf5cf9c4a5e457384e0b0f73c0163c4
,
Apr 19 2017
,
Apr 19 2017
Given the Cl based on the bisect states there is no behavioral change, I am not 100% sure if this is an issue with Chrome or something to do with Google Doc's side, If it's Google docs can someone please redirect to Google Docs team.
,
Apr 20 2017
,
Apr 20 2017
,
Apr 21 2017
This is cause by my CL[1] mentioned in #c5.
When I change RootEditableElementOfSelection() as below:
base = HTML@1 == BODY
start = BODY@0
result = null
expected = BODY
It seems an implementation of RootEditableElementOf(const Position&) -> Element* is wrong.
Element* RootEditableElementOfSelection(const FrameSelection& selection) {
const auto& base = selection.GetSelectionInDOMTree().Base();
auto* const result = RootEditableElementOf(base);
const auto& start = selection.ComputeVisibleSelectionInDOMTreeDeprecated().Start();
auto* const expected = RootEditableElementOf(start);
DCHECK_EQ(result, expected) << " base=" << base << " start=" << start;
return result;
}
[1] http://crrev.com/2782413002 Get rid of computeVisibleSelectionInDOMTreeDeprecated() in InputMethodController::textInputType() and textInputInfo()
,
Apr 21 2017
Thanks Yosin - we are aiming to get M59 promoted to beta next week, and planning on doing a RC by EOD monday. Since this is marked as RB-Beta, please get the change in before then.
,
Apr 24 2017
,
Apr 24 2017
I filed b/37615256 (google internal only) to change Google Docs and Google Presentations.
,
Apr 24 2017
In review: http://crrev.com/2834343002
,
Apr 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f0600844152acd9e12e486ecfd49ae492f67517c commit f0600844152acd9e12e486ecfd49ae492f67517c Author: yosin <yosin@chromium.org> Date: Mon Apr 24 09:38:45 2017 Make InputMethodController::TextInputType() to use canonicalized position Make InputMethodController::TextInputType() to use canonicalized position This patch changes |RootEditableElementOfSelection()| to use canonicalized position as workaround for applications depend buggy behavior of Blink. Before patch[1], |InputMethodController| to check editability of selection by using |VisibleSelection::Start()|. After patch[1], |InputMethodController| to use |SelectionInDOMTree::Base()|. The buggy behavior of Blink caused by using |VisibleSelection::Start()| which returns inside of editable even if scripts specified before editable. For example, simpler version of Google Docs/Presentations: <html> <head>...</head> <body contenteditable>...</body> </html> Google Docs/Presentations set selection to a position HTML@1 where before BODY element. In this case, |VisibleSelection::Start()| == BODY@0 due by visible position canonicalization. [1] http://crrev.com/2782413002 Get rid of computeVisibleSelectionInDOMTreeDeprecated() in InputMethodController BUG=711396, 712761 , 714507 TEST=run_webkit_unit_tests --gtest_filter=InputMethodControllerTest.TextInputTypeAtBeforeEditable Review-Url: https://codereview.chromium.org/2834343002 Cr-Commit-Position: refs/heads/master@{#466612} [modify] https://crrev.com/f0600844152acd9e12e486ecfd49ae492f67517c/third_party/WebKit/Source/core/editing/InputMethodController.cpp [modify] https://crrev.com/f0600844152acd9e12e486ecfd49ae492f67517c/third_party/WebKit/Source/core/editing/InputMethodControllerTest.cpp
,
Apr 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/60cfc544d6a46df2a54cb222f12fdf12a48d73f0 commit 60cfc544d6a46df2a54cb222f12fdf12a48d73f0 Author: Alex Mineer <amineer@chromium.org> Date: Mon Apr 24 17:48:28 2017 Make InputMethodController::TextInputType() to use canonicalized position Make InputMethodController::TextInputType() to use canonicalized position This patch changes |RootEditableElementOfSelection()| to use canonicalized position as workaround for applications depend buggy behavior of Blink. Before patch[1], |InputMethodController| to check editability of selection by using |VisibleSelection::Start()|. After patch[1], |InputMethodController| to use |SelectionInDOMTree::Base()|. The buggy behavior of Blink caused by using |VisibleSelection::Start()| which returns inside of editable even if scripts specified before editable. For example, simpler version of Google Docs/Presentations: <html> <head>...</head> <body contenteditable>...</body> </html> Google Docs/Presentations set selection to a position HTML@1 where before BODY element. In this case, |VisibleSelection::Start()| == BODY@0 due by visible position canonicalization. [1] http://crrev.com/2782413002 Get rid of computeVisibleSelectionInDOMTreeDeprecated() in InputMethodController BUG=711396, 712761 , 714507 TEST=run_webkit_unit_tests --gtest_filter=InputMethodControllerTest.TextInputTypeAtBeforeEditable (cherry picked from commit f0600844152acd9e12e486ecfd49ae492f67517c) Review-Url: https://codereview.chromium.org/2834343002 Cr-Original-Commit-Position: refs/heads/master@{#466612} Cr-Commit-Position: refs/branch-heads/3071@{#169} Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641} [modify] https://crrev.com/60cfc544d6a46df2a54cb222f12fdf12a48d73f0/third_party/WebKit/Source/core/editing/InputMethodController.cpp [modify] https://crrev.com/60cfc544d6a46df2a54cb222f12fdf12a48d73f0/third_party/WebKit/Source/core/editing/InputMethodControllerTest.cpp
,
Apr 25 2017
,
Apr 25 2017
Verified this issue on Windows-10, Ubuntu 14.04 and Mac OS 10.12.4 using chrome latest Dev #59.0.3071.25 by following steps mentioned in the original comment. Observed able to type the Korean language in the google docs body area. Hence adding TE-Verified label. Thanks!
,
Apr 25 2017
Verified in Chrome 59.0.3071.25/ CrOS 9460.11.0 (Peppy/Paine), Chrome 60.0.3080.0-canary(Win7).
,
Apr 25 2017
|
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by songsuk@chromium.org
, Apr 18 2017