New issue
Advanced search Search tips

Issue 829699 link

Starred by 3 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Edit Bookmarks: Scroll position jumps on first mouse click

Reported by jiayinhu...@gmail.com, Apr 6 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce the problem:
1. Have lots of existing bookmarks (so that you can scroll)
2. Add a new bookmark: Click the star next to the URL bar, click the combobox next to Folder, and select "Choose another folder..." to open the Edit Bookmark window
3. Click something inside the scroll view

What is the expected behavior?
Nothing

What went wrong?
Scroll position jumps unexpectedly.

- If I expand a folder by clicking the little triangle to the left of the folder name, the scroll view always jumps to the very top.
- If I click on a folder, the scroll view jumps so that the new highlighted folder is at the very bottom of the scroll view
- If I click on empty white space, the scroll view also jumps to the very top

Note that this only happens on the first click inside the Edit Bookmark window. After that first click and jump, expected behaviour is observed for all subsequent clicks; i.e., clicks do not cause the scroll view to jump.

Did this work before? Yes This bug appeared relatively recently (within the last couple of months). I'm _pretty_ sure the bug wasn't present in version 64.

Chrome version: 65.0.3325.181  Channel: stable
OS Version: 6.3
Flash Version: 

Possibly related to Issue 825292
 
Step 1 clarification: Sorry, I meant bookmark *folders*.
Labels: Needs-Bisect Needs-Triage-M65
Cc: susan.boorgula@chromium.org
Components: UI>Browser>Bookmarks
Labels: -Pri-2 -Needs-Bisect hasbisect-per-revision ReleaseBlock-Stable Triaged-ET RegressedIn-65 M-66 FoundIn-66 Target-67 Target-66 Target-65 FoundIn-65 FoundIn-67 OS-Linux Pri-1
Owner: kylixrd@chromium.org
Status: Assigned (was: Unconfirmed)
jiayinhuang3.14159@ Thanks for the issue.

Able to reproduce this issue on Windows 10 and Ubuntu 14.04 on the latest Canary 67.0.3390.0 and Stable 65.0.3325.181 as per the original comment.
Unable to reproduce the issue on Mac OS 10.13.3.

Bisect Information:
===================
Good Build: 65.0.3286.0 (Revision - 521956)
Bad Build : 65.0.3287.0 (Revision - 522296)

On executing the per-revision bisect script, below is the Changelog URL:

https://chromium.googlesource.com/chromium/src/+log/75ac1cc62531300cdf2e430718ff8d91511c1739..5eaac482ef2f7f68eab47d1874a3d2a69efeff33

From the above Changelog, suspecting the below change:
Reviewed-on:  https://chromium-review.googlesource.com/806256

kylixrd@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner.

Adding ReleaseBlock-Stable for M-66 as this is a recent regression. Please feel free to remove if it is not applicable.

Thanks.
Reminder: Please note that M66 Stable is only 7 days away. This bug has been marked as ReleaseBlock Stable for M66. So please take a look and appropriately address this bug. 
Cc: bsep@chromium.org
This bug seems to be harmony related. 

Comment 6 Deleted

kylixrd@,

As M-66 stable is being rolled out today ,could you please confirm this bug should still be tagged as M-66 stable blocker?
Thanks..!
Friendly ping to get an update on this issue as per C#7?
Thanks..!

Comment 9 by bsep@chromium.org, Apr 24 2018

Labels: -ReleaseBlock-Stable
Not RBS. Allen, please look at this when you have time.
news on this? :-)

Labels: Hotlist-DesktopUIChecked Hotlist-DesktopUIValid
*** UI Mass Triage***

Adding labels for expert review.Unable to reproduce from TE end on latest canary#72.0.3622.0

Sign in to add a comment