Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1780923004:
Don't reveal text selection when finishing composition. (Closed)
DescriptionDon't reveal text selection when finishing composition.
Please see https://crbug.com/587458 for context.
BUG=587458
Committed: https://crrev.com/3cabd97ab0cd2b93ab3b49ab34dda2ce75898e15
Cr-Commit-Position: refs/heads/master@{#384673}
Patch Set 1 #Patch Set 2 : added finishComposition and unittest #
Total comments: 9
Patch Set 3 : #
Total comments: 2
Patch Set 4 : nits #Patch Set 5 : rebase master #Patch Set 6 : fix oilpan bot #
Messages
Total messages: 34 (10 generated)
[email protected] changed reviewers: + [email protected], [email protected]
Please see comment #11 on crbug.com/587458 for context.
So what's happening is that first the IPC to cancel the composition is sent, it starts a scroll, and then by the time the GestureTap arrives it's not at the right place? Is that right? If so, this change seems reasonable, is there a way to test this?
Not sure about side effect. This change behavior for setting composition from existing text. Can we cancel composition when focus is moved? I think once composition lost focus, it should be canceled or commit.
On 2016/03/11 00:17:41, aelias wrote: > So what's happening is that first the IPC to cancel the composition is sent, it > starts a scroll, and then by the time the GestureTap arrives it's not at the > right place? Is that right? > I think the sequence of events is as follows: 1) The user hits "submit" while an input field is focused, but out of viewport and the OSK is suggesting a word (ongoing composition) 2) GestureTap gets called 3) GestureTap does a hittest for mousedown, and the position of the hittest is where the submit button is 4) We change focus, cancel the ongoing composition (IPC to android to cancel composition). This is where the function in the CL above gets called and we erroneously scroll the input field into view. 5) GestureTap does a hittest for mouseup, and the position of the hittest this time is no longer the submit button, and the correct handler for the "submit" button doesn't get called. > If so, this change seems reasonable, is there a way to test this? Once the change looks good, I was thinking of adding a browser test for this.
On 2016/03/11 05:12:42, Yosi_UTC9 wrote: > Not sure about side effect. This change behavior for setting composition from > existing text. > > Can we cancel composition when focus is moved? I think once composition lost > focus, it should be canceled or commit. I think we currently cancel composition when focus is moved (or at least that's what we aim to). This is the method that gets called and eventually calls confirmComposition() https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/r.... The comments on the method suggest that "When this method gets called, WebWidgetClient implementation should reset the input method by cancelling any ongoing composition." It is not clear to me what it means to "confirmComposition". confirmComposition in this case effectively does nothing but call InputMethodController::clear(). https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/r... I am also not entirely sure why we do the scrolling into view logic in Editor::RevealSelectionScope and for what cases it makes sense.
Gentle ping :)
On 2016/03/11 at 15:16:17, ymalik wrote: > On 2016/03/11 05:12:42, Yosi_UTC9 wrote: > > Not sure about side effect. This change behavior for setting composition from > > existing text. > > > > > Can we cancel composition when focus is moved? I think once composition lost > > focus, it should be canceled or commit. > > I think we currently cancel composition when focus is moved (or at least that's what we aim to). This is the method that gets called and eventually calls confirmComposition() https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/r.... The comments on the method suggest that "When this method gets called, WebWidgetClient implementation should reset the input method by cancelling any ongoing composition." > > It is not clear to me what it means to "confirmComposition". Can we introduce finishComposition(), which does what confirmComposition() does except revealing selection. > confirmComposition in this case effectively does nothing but call InputMethodController::clear(). > https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/r... > > I am also not entirely sure why we do the scrolling into view logic in Editor::RevealSelectionScope and for what cases it makes sense. +kochi@, who is a expert of desktop IME.
[email protected] changed reviewers: + [email protected]
On 2016/03/15 at 01:34:43, yosin wrote: > Can we introduce finishComposition(), which does what confirmComposition() does except revealing selection. Yeah, I tend to agree we should never reveal selection when the composition was finished due to focus change. That would also fix this bug in the case where the text was actively typed. > Once the change looks good, I was thinking of adding a browser test for this. I recommend writing a Blink-side unit test e.g. in WebViewTest or InputMethodControllerTest instead. Those are usually faster and less flaky, and you can call all the necessary methods from there.
@yosin, @aelias PTAL :)
Description was changed from ========== Speculative fix for submit button not working when input field out of viewport. Please see https://crbug.com/587458 for context. BUG=587458 ========== to ========== Don't reveal text selection when finishing composition. Please see https://crbug.com/587458 for context. BUG=587458 ==========
lgtm w/ nit Please wait for aelias@ for OWNERE of Source/web. https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/editing/InputMethodController.cpp (right): https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/core/editing/InputMethodController.cpp:150: if (!hasComposition()) Could you add following lines before |RevealSelectionScope| == L143, to keep current |confirmComposition()| behavior? https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... File third_party/WebKit/Source/web/tests/WebViewTest.cpp (right): https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/web/tests/WebViewTest.cpp:984: RefPtrWillBeRawPtr<Element> element = static_cast<PassRefPtrWillBeRawPtr<Element>>(webView->mainFrame()->document().getElementById("btn")); nit: I think we don't need to have |static_cast<>| here. https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... File third_party/WebKit/Source/web/tests/data/form_with_input.html (right): https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/web/tests/data/form_with_input.html:1: <style> nit: Could you add <!doctype html> to use strict mode? Since most sties use strict mode. https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/web/tests/data/form_with_input.html:7: nit: nuke an extra blank line
https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/editing/InputMethodController.h (right): https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/core/editing/InputMethodController.h:68: bool finishComposition(const String& text); This method isn't called from outside the class, so we shouldn't add it as a new public method. Also, wouldn't it make more sense to instead pass down the ConfirmCompositionBehavior enum as an argument to the existing method confirmComposition()?
https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/editing/InputMethodController.h (right): https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/core/editing/InputMethodController.h:68: bool finishComposition(const String& text); On 2016/03/24 01:48:40, aelias wrote: > This method isn't called from outside the class, so we shouldn't add it as a new > public method. > > Also, wouldn't it make more sense to instead pass down the > ConfirmCompositionBehavior enum as an argument to the existing method > confirmComposition()? I agree that it may be better than adding a new method without having a good reason, but perhaps it makes the difference between confirmComposition and finishComposition clearer (one reveals text and the other doesn't). I don't have a strong preference, will go with your call. WDYT?
On 2016/03/24 at 02:14:33, ymalik wrote: > https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... > File third_party/WebKit/Source/core/editing/InputMethodController.h (right): > > https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... > third_party/WebKit/Source/core/editing/InputMethodController.h:68: bool finishComposition(const String& text); > On 2016/03/24 01:48:40, aelias wrote: > > This method isn't called from outside the class, so we shouldn't add it as a new > > public method. > > > > Also, wouldn't it make more sense to instead pass down the > > ConfirmCompositionBehavior enum as an argument to the existing method > > confirmComposition()? > > I agree that it may be better than adding a new method without having a good reason, but perhaps it makes the difference between confirmComposition and finishComposition clearer (one reveals text and the other doesn't). > > I don't have a strong preference, will go with your call. WDYT? Yeah, I'd rather have the additional argument, I find that more self-documenting and consistent. You can find some C++ trick or introduce a private method to have the conditional RAII.
On 2016/03/24 at 02:29:42, aelias wrote: > On 2016/03/24 at 02:14:33, ymalik wrote: > > https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... > > File third_party/WebKit/Source/core/editing/InputMethodController.h (right): > > > > https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... > > third_party/WebKit/Source/core/editing/InputMethodController.h:68: bool finishComposition(const String& text); > > On 2016/03/24 01:48:40, aelias wrote: > > > This method isn't called from outside the class, so we shouldn't add it as a new > > > public method. > > > > > > Also, wouldn't it make more sense to instead pass down the > > > ConfirmCompositionBehavior enum as an argument to the existing method > > > confirmComposition()? > > > > I agree that it may be better than adding a new method without having a good reason, but perhaps it makes the difference between confirmComposition and finishComposition clearer (one reveals text and the other doesn't). > > > > I don't have a strong preference, will go with your call. WDYT? > > Yeah, I'd rather have the additional argument, I find that more self-documenting and consistent. You can find some C++ trick or introduce a private method to have the conditional RAII. TL;DR: +1 for adding ConfirmCompositionBehavior to confirmComposition() parameter. It seems I use term "finish composition" opposite: "ime_adapter_android.cc" ImeAdapterAndroid::CommitText() => confirm composition DoNotKeepSelection ImeAdapterAndroid::FinishComposingText() => confirm composition KeepSelection So, make things simpler, it is better not to introduce new term here.
On 2016/03/24 02:29:42, aelias wrote: > On 2016/03/24 at 02:14:33, ymalik wrote: > > > https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... > > File third_party/WebKit/Source/core/editing/InputMethodController.h (right): > > > > > https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... > > third_party/WebKit/Source/core/editing/InputMethodController.h:68: bool > finishComposition(const String& text); > > On 2016/03/24 01:48:40, aelias wrote: > > > This method isn't called from outside the class, so we shouldn't add it as a > new > > > public method. > > > > > > Also, wouldn't it make more sense to instead pass down the > > > ConfirmCompositionBehavior enum as an argument to the existing method > > > confirmComposition()? > > > > I agree that it may be better than adding a new method without having a good > reason, but perhaps it makes the difference between confirmComposition and > finishComposition clearer (one reveals text and the other doesn't). > > > > I don't have a strong preference, will go with your call. WDYT? > > Yeah, I'd rather have the additional argument, I find that more self-documenting > and consistent. You can find some C++ trick or introduce a private method to > have the conditional RAII. @aelias PTAL :) I am wrapping the RevealSelectionScope in Optional. As a result of this, we have to loosen the STACK_ALLOCATED to DISALLOW_NEW_EXCEPT_PLACEMENT_NEW. Another option is to send in a parameter to RevealSelectionScope constructor that tells it to do nothing. WDYT?
lgtm, but please wait for yosin@ to review the Editor.h change before landing. (Personally, I think the PLACEMENT_NEW change is fine because this is the most readable way to write the code and the performance regression should be negligible.)
https://codereview.chromium.org/1780923004/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/editing/InputMethodController.cpp (right): https://codereview.chromium.org/1780923004/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/editing/InputMethodController.cpp:144: Optional<Editor::RevealSelectionScope> revealSelectionScope; How about make |RevealSelectionScope| to take |nullptr|? If so, we could write: Editor::RevealSelecitonScope revealScope(confirmBehavior == KeepSelection ? &editor() : nullptr); Yet, another option (need more code change) is rename |RevealExtentOption| to |RevealSelectionOption| with adding |DoNotRevealSelection|, and make |RevealSelectionScope| to take |RevealSelectionOption|, default is |RevealExtent|: Editor::RevealSelecitonScope revealScope(&editor(), confirmBehavior == KeepSelection ? RevealExtent : DoNotRevealSelection);
@yosin, ptal :) https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... File third_party/WebKit/Source/web/tests/WebViewTest.cpp (right): https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/web/tests/WebViewTest.cpp:984: RefPtrWillBeRawPtr<Element> element = static_cast<PassRefPtrWillBeRawPtr<Element>>(webView->mainFrame()->document().getElementById("btn")); On 2016/03/24 01:19:16, Yosi_UTC9 wrote: > nit: I think we don't need to have |static_cast<>| here. Done. https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... File third_party/WebKit/Source/web/tests/data/form_with_input.html (right): https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/web/tests/data/form_with_input.html:1: <style> On 2016/03/24 01:19:17, Yosi_UTC9 wrote: > nit: Could you add <!doctype html> to use strict mode? > Since most sties use strict mode. Done. https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/web/tests/data/form_with_input.html:7: On 2016/03/24 01:19:17, Yosi_UTC9 wrote: > nit: nuke an extra blank line Done. https://codereview.chromium.org/1780923004/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/editing/InputMethodController.cpp (right): https://codereview.chromium.org/1780923004/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/editing/InputMethodController.cpp:144: Optional<Editor::RevealSelectionScope> revealSelectionScope; On 2016/03/25 01:19:35, Yosi_UTC9 wrote: > How about make |RevealSelectionScope| to take |nullptr|? > If so, we could write: > > Editor::RevealSelecitonScope revealScope(confirmBehavior == KeepSelection ? > &editor() : nullptr); > > Yet, another option (need more code change) is rename |RevealExtentOption| to > |RevealSelectionOption| with adding |DoNotRevealSelection|, and make > |RevealSelectionScope| to take |RevealSelectionOption|, default is > |RevealExtent|: > > Editor::RevealSelecitonScope revealScope(&editor(), confirmBehavior == > KeepSelection ? RevealExtent : DoNotRevealSelection); > Is there a reason why using Optional is not preferred here? I personally like it better than passing in a nullptr or parameter because to me it's more clear that we may optionally RevealSelectionScope. I find it odd to pass in "DoNotRevealSelection" to "RevealSelectionScope". Is it okay to leave this as is?
On 2016/03/29 at 20:46:20, ymalik wrote: > @yosin, ptal :) > > https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... > File third_party/WebKit/Source/web/tests/WebViewTest.cpp (right): > > https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... > third_party/WebKit/Source/web/tests/WebViewTest.cpp:984: RefPtrWillBeRawPtr<Element> element = static_cast<PassRefPtrWillBeRawPtr<Element>>(webView->mainFrame()->document().getElementById("btn")); > On 2016/03/24 01:19:16, Yosi_UTC9 wrote: > > nit: I think we don't need to have |static_cast<>| here. > > Done. > > https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... > File third_party/WebKit/Source/web/tests/data/form_with_input.html (right): > > https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... > third_party/WebKit/Source/web/tests/data/form_with_input.html:1: <style> > On 2016/03/24 01:19:17, Yosi_UTC9 wrote: > > nit: Could you add <!doctype html> to use strict mode? > > Since most sties use strict mode. > > Done. > > https://codereview.chromium.org/1780923004/diff/20001/third_party/WebKit/Sour... > third_party/WebKit/Source/web/tests/data/form_with_input.html:7: > On 2016/03/24 01:19:17, Yosi_UTC9 wrote: > > nit: nuke an extra blank line > > Done. > > https://codereview.chromium.org/1780923004/diff/40001/third_party/WebKit/Sour... > File third_party/WebKit/Source/core/editing/InputMethodController.cpp (right): > > https://codereview.chromium.org/1780923004/diff/40001/third_party/WebKit/Sour... > third_party/WebKit/Source/core/editing/InputMethodController.cpp:144: Optional<Editor::RevealSelectionScope> revealSelectionScope; > On 2016/03/25 01:19:35, Yosi_UTC9 wrote: > > How about make |RevealSelectionScope| to take |nullptr|? > > If so, we could write: > > > > Editor::RevealSelecitonScope revealScope(confirmBehavior == KeepSelection ? > > &editor() : nullptr); > > > > Yet, another option (need more code change) is rename |RevealExtentOption| to > > |RevealSelectionOption| with adding |DoNotRevealSelection|, and make > > |RevealSelectionScope| to take |RevealSelectionOption|, default is > > |RevealExtent|: > > > > Editor::RevealSelecitonScope revealScope(&editor(), confirmBehavior == > > KeepSelection ? RevealExtent : DoNotRevealSelection); > > > > Is there a reason why using Optional is not preferred here? I personally like it better than passing in a nullptr or parameter because to me it's more clear that we may optionally RevealSelectionScope. I find it odd to pass in "DoNotRevealSelection" to "RevealSelectionScope". > > Is it okay to leave this as is? lgtm Yes, it is OK as is. I have no strong preference whether using |Optional| or not. IMHO, passing |nullptr| is more clear. Anyway, it is my personal preference and it should not stop the world. Here is my story about |WTF::Optional|: One day I want to have |Maybe<T>| in WebKit. I did code search but not found. I realize Swift introduce |Optional| type similar to |Maybe<T>|. I did code search and found |WTF::Optional|. However, it is an alias of |std::unique_ptr<T>| or |WTF::OwnPtr<T>| and it comes from boost and in |std::experimental::optional<T>|. My reasoning was that |optional<T>| isn't popular. I just google today and I found Java also has Optional<T> like Maybe<T>.
The CQ bit was checked by [email protected]
The patchset sent to the CQ was uploaded after l-g-t-m from [email protected], [email protected] Link to the patchset: https://codereview.chromium.org/1780923004/#ps80001 (title: "rebase master")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1780923004/80001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1780923004/80001
The CQ bit was unchecked by [email protected]
Try jobs failed on following builders: linux_blink_oilpan_rel on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_blink_oil...)
The CQ bit was checked by [email protected]
The patchset sent to the CQ was uploaded after l-g-t-m from [email protected], [email protected] Link to the patchset: https://codereview.chromium.org/1780923004/#ps100001 (title: "fix oilpan bot")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1780923004/100001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1780923004/100001
Message was sent while issue was closed.
Description was changed from ========== Don't reveal text selection when finishing composition. Please see https://crbug.com/587458 for context. BUG=587458 ========== to ========== Don't reveal text selection when finishing composition. Please see https://crbug.com/587458 for context. BUG=587458 ==========
Message was sent while issue was closed.
Committed patchset #6 (id:100001)
Message was sent while issue was closed.
Description was changed from ========== Don't reveal text selection when finishing composition. Please see https://crbug.com/587458 for context. BUG=587458 ========== to ========== Don't reveal text selection when finishing composition. Please see https://crbug.com/587458 for context. BUG=587458 Committed: https://crrev.com/3cabd97ab0cd2b93ab3b49ab34dda2ce75898e15 Cr-Commit-Position: refs/heads/master@{#384673} ==========
Message was sent while issue was closed.
Patchset 6 (id:??) landed as https://crrev.com/3cabd97ab0cd2b93ab3b49ab34dda2ce75898e15 Cr-Commit-Position: refs/heads/master@{#384673} |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
