[MacViewsBrowser] When dragging bookmark, a space does not “open up” for the new bookmark’s position |
|||||||||||||
Issue descriptionChrome Version: 60.0.3072.0 (MacViews) OS: macOS 10.12 What steps will reproduce the problem? (1) Drag a bookmark left or right across the bookmarks bar What is the expected result? As you drag, a space should open up in the bookmarks bar for the spot where the bookmark will live. What happens instead? A black vertical bar appears between items showing where the bookmark will live. The bookmark remains visible in its original location, even though it's also being dragged by the mouse.
,
Feb 8 2018
[Bulk Edit] Applying M-68 milestone per email discussion with ellyjones@. Pls change it if milestone is incorrectly applied.
,
Mar 23 2018
MacViews triage: lgrey@, let's target this for M-69.
,
Mar 27 2018
,
May 10 2018
,
May 10 2018
,
May 23 2018
,
Jun 20 2018
,
Jul 12
,
Jul 12
,
Jul 23
Issue 712248 is relevant.
,
Jul 24
sdy@ was c#11 meant to go elsewhere? This is that selfsame issue :)
,
Jul 24
Whoops. I meant issue 166672.
,
Jul 24
Nice find. ellyjones@ WDYT? I think the argument in issue 166672 makes sense (though I more or less agree with asvitkine@ in c#6), but it was made a while ago and users have now had many years to get used to the Cocoa behavior.
,
Jul 24
Also +bettes@
,
Jul 31
,
Aug 3
Per offline conversation with bettes@, we're going forward with this, issue 166672 notwithstanding.
,
Aug 17
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c749d1a7c1b700d60797bea7f7d22830aef7ccce commit c749d1a7c1b700d60797bea7f7d22830aef7ccce Author: Leonard Grey <lgrey@chromium.org> Date: Fri Aug 17 17:50:32 2018 Track bookmark bar buttons independently of the parent's hierarchy Currently, the bookmark bar uses the view hierarchy as its "model": bookmark buttons are force ordered to the child view index that matches their order in the model node (so that child_at(i) is the ith button), and GetBookmarkButtonCount() is implemented as: `return child_count() - 6;` This is fragile, and less than ideal for keyboard traversal. This change tracks the buttons separately in a vector, and maintains proper focus traversal. This is setup for Cocoa-style button dragging (as well as a fix for issue 841785 ). Bug: 712248, 841785 Change-Id: I236e34503d021ff0f27974f731f6abcb4d62f829 Reviewed-on: https://chromium-review.googlesource.com/1177908 Commit-Queue: Leonard Grey <lgrey@chromium.org> Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org> Cr-Commit-Position: refs/heads/master@{#584117} [modify] https://crrev.com/c749d1a7c1b700d60797bea7f7d22830aef7ccce/chrome/browser/ui/views/bookmarks/bookmark_bar_view.cc [modify] https://crrev.com/c749d1a7c1b700d60797bea7f7d22830aef7ccce/chrome/browser/ui/views/bookmarks/bookmark_bar_view.h [modify] https://crrev.com/c749d1a7c1b700d60797bea7f7d22830aef7ccce/chrome/browser/ui/views/bookmarks/bookmark_bar_view_test_helper.h [modify] https://crrev.com/c749d1a7c1b700d60797bea7f7d22830aef7ccce/chrome/browser/ui/views/bookmarks/bookmark_bar_view_unittest.cc
,
Nov 21
**UI mass Triage** Able to reproduce the issue on Win, Mac using Canary #72.0.3616.0 adding labels for expert review. |
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by tapted@chromium.org
, Jun 8 2017Labels: Phase4