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

Issue 854996 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Jun 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression: Focus get lost from close(X) button after deleting first download entry on Download page.

Reported by dchau...@etouch.net, Jun 21 2018

Issue description

Chrome Version: 69.0.3466.0 (Official Build) Revision	7a22a4a62948746c970b84f31b1f78cd2cb3a1c2-refs/branch-heads/3466@{#1} 32/64-bit.
OS: Windows(7,8,8.1,10), Mac(10.12.6 , 10.13.1 , 10.13.6) and Linux(14.04 LTS).

What steps will reproduce the problem?
1. Launch chrome, navigate to https://speed.hetzner.de/ and click on 2-3 files to download.
2. Navigate to chrome://downloads/ page and cancel all the downloads.
3. Press 'Tab' key such that focus reaches to first download entry of close(X) button.
4. Now 2-3 times press 'Enter' key from key keyboard and observe.

Actual: List of download entry doesn't get deleted on pressing 'Enter' key i.e. focus is lost after deleting first download entry.
Expected: List of download entry should get deleted on pressing 'Enter' key i.e. focus should not lost from close(X) button.

This is a regression issue broken in M-68 series, below is manual regression range:

Good build: 68.0.3400.0 (Revision: 551876)
Bad build: 68.0.3401.0  (Revision: 552221)

You are probably looking for a change made after 552148 (known good), but no later than 552149 (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/54d6ad62258f03e21bf918d647686bd7b8aa4d15..9417cbbdf2bf0fb3b82cc20e0b0e5cd808d71b16

Suspecting: https://chromium.googlesource.com/chromium/src/+/9417cbbdf2bf0fb3b82cc20e0b0e5cd808d71b16

@scottchen: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

NOTE: This issue is also reproducible on Beta build #68.0.3440.33

Kindly review the attached screen-cast for reference.

Thank you.
 
Actual behavior.mp4
451 KB View Download
Expected behavior.mp4
506 KB View Download
Status: WontFix (was: Assigned)
This is Working as intended. The behavior currently captured as "expected" is accidentally working that way because of how iron-list recycles DOM nodes, and we haven't intended for the x focus to carry over to the next item.

Sign in to add a comment