New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 756331 link

Starred by 2 users
Status: Fixed
Owner:
█ scottchen@chromium.org
Last visit > 30 days ago
Closed: Sep 2017
Cc:
█ hdodda@chromium.org
dpa...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Password manager focus jumps to top of page after edit

Reported by mr.ber...@gmail.com, Aug 17 2017 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36

Steps to reproduce the problem:
0. Plan to remove 5-10 entries from chrome://settings/passwords, all near the end of the list
1. Go to chrome://settings/passwords
2. Scroll of end of list
3. Delete one

What is the expected behavior?
You can delete the next one right away

What went wrong?
The focus jumps back to the top of the page. Instead, it should return to where it was before deleting an entry from the password manager.

Did this work before? N/A 

Chrome version: 60.0.3112.101  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 26.0 r0

Something similar happens when you leave chrome://settings/passwords open while storing a new password (or updating/deleting one) in a different tab. Again, the focus in the password manager jumps to the top of the page.

Comment 1 by hdodda@chromium.org, Aug 23 2017

Cc: hdodda@chromium.org
Components: -UI UI>Settings
Labels: -Type-Bug -Pri-2 hasbisect-per-revision M-61 Needs-Triage-M60 OS-Linux OS-Mac Pri-1 Type-Bug-Regression
Owner: scottchen@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on windows 10 , mac os 10.12.6 and ubuntu 14.04 using M60 #60.0.3112.101 .

Issue is fixed in latest beta , dev and canary channels.Hence providing the reverse bisect results,

Using the per-revision bisect providing the bisect results,
Good build: 61.0.3140.0(Revision: 482096).
Bad build:61.0.3138.0 (Revision: 481386).

You are probably looking for a change made after 482050 (known good), but no later than 482051 (first known bad).

CHANGELOG URL:

The script might not always return single CL as suspect as some perf builds might get missing due to failure.
  https://chromium.googlesource.com/chromium/src/+log/d919876ae05ce9d17ee8989543ae96d4b03176ac..20547cb0499f83a89e55c1cc222fffe4eac89a70

Review-Url: https://codereview.chromium.org/2949873003

@scottchen-- Could you please merge the fix to the M60 .

Thanks!

Comment 2 by manoranj...@chromium.org, Aug 29 2017

Labels: -Needs-Triage-M60

Comment 3 by scottchen@chromium.org, Aug 30 2017

Status: Started (was: Assigned)

Comment 4 by scottchen@chromium.org, Aug 30 2017

Labels: Needs-Feedback
Not sure what's going on here, but the fix identified by the bisect was already in master 2 months ago, so it should've already been in M60?

Comment 5 by scottchen@chromium.org, Sep 8 2017

Status: Fixed (was: Started)
Checked M61 build and unable to reproduce, marking as fixed.
►

Sign in to add a comment