Folder name shift upward after dragging url on it in bookmark bar.
Reported by
vku...@etouch.net,
Sep 8 2017
|
||||||
Issue descriptionChrome Version: 62.0.3202.13 (Official Build) 8aba0a34f8ab922b12535ce172e7ae6434d8e603-refs/branch-heads/3202@{#75}(64-bit) OS:Mac(10.11.6, 10.12.3, 10.12.5) What steps will reproduce the problem? (1)Launch chrome and navigate to chrome://bookmarks/,click on iron icon near search field (2)Add new folder ,again add new folder inside it and bookmark any webpage under the current folder. (3)Press cmd+shift+B click on folder, drag url onto the left side of folder and observe. Actual: Folder name shift upward after dragging url on it in bookmark bar. Expected: Folder name should not shift upward after dragging url on it in bookmark bar. This is a Non-regression issue seen from 'M59' series i.e 59.0.3030.0 Note: Issue not seen on Win & Linux OS.
,
Sep 15 2017
[mac bug triage] lgrey@ - PTAL. Let's discuss if it's looking like it will be a lot of work to fix.
,
Sep 20 2017
Assigning this to myself to get it out of triage
,
Sep 20 2017
,
Sep 20 2017
,
Sep 21 2017
Initial brain dump:
Seems like the bug here is that it stays scrolled after the drag. This all seems to happen via underdocumented AppKit magic (see backtrace below). We certainly want it to be *able* to scroll (both to indicate drop targets at the top and bottom and to scroll long menus), so the trick here would be to "reset" the scroll position after the drag is canceled.
I think trying to mess with this has a high chance of breaking some kind of intended behavior, so my inclination is to just punt until views.
* thread #1: tid = 0xd5ba30, 0x00007fff97997119 AppKit`-[NSClipView scrollToPoint:], name = 'CrBrowserMain', queue = 'com.apple.main-thread', stop reason = breakpoint 3.1
* frame #0: 0x00007fff97997119 AppKit`-[NSClipView scrollToPoint:]
frame #1: 0x00007fff979d4191 AppKit`-[NSScrollView scrollClipView:toPoint:] + 78
frame #2: 0x00007fff9797cbc7 AppKit`-[NSClipView _scrollTo:animateScroll:flashScrollerKnobs:] + 1652
frame #3: 0x00007fff97d66eb7 AppKit`-[NSClipView _autoscrollForDraggingInfo:timeDelta:] + 1819
frame #4: 0x00007fff97b5188e AppKit`NSCoreDragTrackingProc + 2258
frame #5: 0x00007fff98a8dbbf HIServices`DoTrackingMessage + 399
frame #6: 0x00007fff98a8edf8 HIServices`SendTrackingMessage + 112
frame #7: 0x00007fff98a8e029 HIServices`DragInApplication + 285
frame #8: 0x00007fff98a8d0b3 HIServices`CoreDragStartDragging + 925
frame #9: 0x00007fff97b5092c AppKit`-[NSCoreDragManager _dragUntilMouseUp:accepted:] + 1048
frame #10: 0x00007fff97e249fa AppKit`_handleBeginDraggingSession + 97
frame #11: 0x00007fff99dd9de7 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
frame #12: 0x00007fff99dd9d57 CoreFoundation`__CFRunLoopDoObservers + 391
frame #13: 0x00007fff99dba529 CoreFoundation`CFRunLoopRunSpecific + 393
frame #14: 0x00007fff9b7eb252 Foundation`-[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 277
frame #15: 0x00000001089b52eb libchrome_dll.dylib`::-[BookmarkButton beginDrag:](self=0x000000014e48b120, _cmd="beginDrag:", event=0x0000000157eb6870) + 2027 at bookmark_button.mm:229
,
Sep 25
Archiving old bugs that have only received trivial updates for some time. If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks! |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by msrchandra@chromium.org
, Sep 8 2017