[MacViews] Mouse turns to arrow over selected editable text in a textfield |
|||||||
Issue descriptionChrome Version: 65.0.3293.0 OS: macOS 10.12 What steps will reproduce the problem? (1) Bring up the Bookmarks bubble (2) Select a portion of the text in the name textfield (3) Move the mouse over the text What is the expected result? The mouse cursor should always be an I-beam cursor. What happens instead? The cursor is an arrow cursor when over the text selection, and an I-beam elsewhere. It appears that Views shows an arrow to indicate that the selection is draggable. I don't think this is the right thing to do because text dragging is rare and the implication of an arrow over text is that the text is not editable or selectable. In any case, on the Mac the cursor is always an I-beam (it turns to an arrow when you start dragging the text).
,
Jan 11 2018
Load balancing! sdy@, can you take a peek at this please? :)
,
Jan 29 2018
,
Feb 7 2018
Yoink! Started: <https://chromium-review.googlesource.com/c/chromium/src/+/906952>
,
Feb 7 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/59f334689bb858cf6229446cc8fca7c6d9f0e828 commit 59f334689bb858cf6229446cc8fca7c6d9f0e828 Author: Elly Fong-Jones <ellyjones@chromium.org> Date: Wed Feb 07 18:50:57 2018 views: support Mac behavior for textfield cursors On Mac, textfields retain the ibeam cursor when the mouse is over a selection, while on other platforms they use an arrow cursor to indicate availability to drag. Bug: 794596 Change-Id: I4a6f9ab602c9afcea998c6d97499e216e10ddbb3 Reviewed-on: https://chromium-review.googlesource.com/906952 Reviewed-by: Michael Wasserman <msw@chromium.org> Commit-Queue: Elly Fong-Jones <ellyjones@chromium.org> Cr-Commit-Position: refs/heads/master@{#535075} [modify] https://crrev.com/59f334689bb858cf6229446cc8fca7c6d9f0e828/ui/views/controls/textfield/textfield.cc [modify] https://crrev.com/59f334689bb858cf6229446cc8fca7c6d9f0e828/ui/views/style/platform_style.cc [modify] https://crrev.com/59f334689bb858cf6229446cc8fca7c6d9f0e828/ui/views/style/platform_style.h [modify] https://crrev.com/59f334689bb858cf6229446cc8fca7c6d9f0e828/ui/views/style/platform_style_mac.mm
,
Feb 7 2018
,
Feb 8 2018
Verified the fix on Mac 10.12.6 on Chrome version #66.0.3343.0 as per the comment#1 Attaching screen shot for reference. Observed the mouse cursor as an I-beam cursor on the text. Hence, the fix is working as expected. Adding the verified labels. Thanks
,
Feb 8 2018
Thanks TE! :) |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by tapted@chromium.org
, Dec 14 2017Status: Assigned (was: Untriaged)
Good find! We just need to nerf the logic in gfx::NativeCursor Textfield::GetCursor(const ui::MouseEvent& event) { bool in_selection = GetRenderText()->IsPointInSelection(event.location()); bool drag_event = event.type() == ui::ET_MOUSE_DRAGGED; bool text_cursor = !initiating_drag_ && (drag_event || !in_selection); return text_cursor ? GetNativeIBeamCursor() : gfx::kNullCursor; } i.e. hide it behind a platformstyle constant Interestingly, Edge doesn't show an arrow in its location bar either, but also it doesn't allow the highlighted text to be dragged. WordPad does allow dragging, and changes to an arrow to indicate this (Chrome usually copies its textfield behaviour from WordPad). Also, interestingly, Cocoa NSTextField changes briefly to an arrow when first clicking into a textfield that doesn't already have focus (which results in text being selected). That's probably an AppKit bug though.