MacViews: Textfields should have similar delete backward behavior to NSTextView |
||||||
Issue descriptionIn NSTextView, for some grapheme clusters, deleting backward removes the whole grapheme, rather than a component characters. In Views, this is not so. Specific example here: https://cs.chromium.org/chromium/src/chrome/browser/ui/omnibox/omnibox_view_browsertest.cc?q=omnibox_view_browsertest&sq=package:chromium&dr&l=1655 Since the rules for this are pretty complicated, we can leverage the CFStringGetRangeOfCharacterClusterAtIndex private function to get a range to delete.
,
Mar 29 2018
,
Mar 29 2018
** Bulk Edit ** There are only two M67 dev releases left on 04/03 & 04/10 before M67 branch on 04/12. Please try to land the fix ASAP to trunk so we can move forward with 50%-50% experiment on M67 Canary/Dev (if possible at all). Thank you.
,
Apr 3 2018
** Bulk Edit ** There is only one dev release left 04/10 before M67 branch on 04/12. Please try to land the fix ASAP to trunk so we can move forward with 50%-50% experiment on M67 Canary/Dev (if possible at all). Thank you. FYI: Change/Fix has to be landed in trunk latest by 4:00 PM PT, Friday (04/06) so we can pick it up for next week dev release.
,
Apr 6 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a903c6f4d5b9f2f4ac9461bcffa9d1e5f95237b9 commit a903c6f4d5b9f2f4ac9461bcffa9d1e5f95237b9 Author: Leonard Grey <lgrey@chromium.org> Date: Fri Apr 06 14:13:45 2018 MacViews: delete entire composed glyph when deleting backward This matches NSTextView's behavior by creating a CFString and asking what Cocoa thinks should happen. This also handles UTF-16 surrogate pairs, so this change splits that check to the non-Mac code path. Bug: 826794 Change-Id: I8fce5510e3cd483533699edd1ba33118ce55b44e Reviewed-on: https://chromium-review.googlesource.com/986475 Commit-Queue: Leonard Grey <lgrey@chromium.org> Reviewed-by: Trent Apted <tapted@chromium.org> Reviewed-by: Michael Wasserman <msw@chromium.org> Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org> Cr-Commit-Position: refs/heads/master@{#548769} [modify] https://crrev.com/a903c6f4d5b9f2f4ac9461bcffa9d1e5f95237b9/ui/views/controls/textfield/textfield_model.cc [modify] https://crrev.com/a903c6f4d5b9f2f4ac9461bcffa9d1e5f95237b9/ui/views/controls/textfield/textfield_model_unittest.cc [modify] https://crrev.com/a903c6f4d5b9f2f4ac9461bcffa9d1e5f95237b9/ui/views/style/platform_style.cc [modify] https://crrev.com/a903c6f4d5b9f2f4ac9461bcffa9d1e5f95237b9/ui/views/style/platform_style.h [modify] https://crrev.com/a903c6f4d5b9f2f4ac9461bcffa9d1e5f95237b9/ui/views/style/platform_style_mac.mm
,
Apr 6 2018
Can this be marked as fixed if nothing else is pending?
,
Apr 6 2018
,
Apr 13 2018
@Leonard Grey: Could you please provide reproducible steps to check and confirm the fix from TE end. Thanks!
,
Apr 13 2018
Enter ﾀﾞ or 🕵🏾♂️ into the Omnibox Press the delete key Expected: whole glyph is deleted Not expected: ﾀ or🕵️♂️
,
Apr 20 2018
Able to reproduce this issue on build without fix(67.0.3389.0) hence verifying the fix on latest canary 68.0.3401.0. Observing deletion of entire glyph as mentioned in comment#9. Attaching screencast for reference. As fix is working as expected adding Verified labels. Thanks!
,
Apr 20 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by lgrey@chromium.org
, Mar 28 2018