Issue metadata
Sign in to add a comment
|
Regression: Focus does not travel on Close (X) button at second instance after pressing tab key on chrome://settings/editDictionary page |
||||||||||||||||||||||
Issue descriptionChrome Version: 73.0.3632.0 (Official Build) Revision 914f5b8f721ff5a734bb22a96363191c20c8c3f2-refs/branch-heads/3632@{#1} (32/64 bit) OS: Windows (7, 8, 8.1, 10) Steps to reproduce: 1. Launch chrome, navigate to 'chrome://settings/editDictionary'. 2. Add a new word and delete this word present in 'Custom words'. 3. Again Add a new word and traverse the focus using 'Tab' key. 4. Now Observe the focus over Close (X) button. Actual Result: Focus does not travel on Close (X) button at second instance after pressing tab key. Expected Result: Focus should travel on Close (X) button at every instance after pressing tab key. This is Regression issue seen in M-72, and below is manual Regression range: Good Build: 72.0.3583.0 Bad Build: 72.0.3584.0 Unable to provide bisect using per-revision script as it shows "We don't have enough builds error message", hence providing bisect using chromium bisect. Chromium bisect info: You are probably looking for a change made after 600223 (known good), but no later than 600228 (first known bad). CHANGE-LOG URL: https://chromium.googlesource.com/chromium/src/+log/62f2f8f209a82db0dd5a311eb4f844bddb75c98e..631a939b2b9a02a05cd1db367c7ea7fb17d14f50 Suspecting: https://chromium.googlesource.com/chromium/src/+/177774d57a744b75630cba5507c3bf1ed419aea3 ?? @dpapad: Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner. NOTE: 1. Issue is also seen on M-72 Dev (build #72.0.3626.7). 2. Issue is not seen on Mac (10.13.1, 10.13.6, 10.14.2) and Linux (14.04 LTS). Thank You..!!
,
Dec 6
@rbpotter: Can you take a look? This seems related to the iron-list Polymer 2 fixes?
,
Dec 7
Investigated and this appears to be the result of wrapping the iron-list in a dom-if. It seems that the iron-list doesn't correctly update its tabindex because the dom-if is false until the list has at least one item, which is why this only occurs if all items are removed from the list and only one is added back.
,
Dec 13
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2fce4e670183180174aebc38471a3f66a8c4b1a6 commit 2fce4e670183180174aebc38471a3f66a8c4b1a6 Author: rbpotter <rbpotter@chromium.org> Date: Thu Dec 13 20:03:43 2018 Settings edit dictionary page: Set dom-ifs before adding to word list In Polymer 2, elements behind dom-ifs that are false no longer update, so tabindex was not being set correctly for the first item added to the list if the list had previously been emptied. To fix this, ensure the dom-if is always set to true before adding new items, and always set to false only after all items have been removed from the list. This is done by making hasWords_ a property that is updated manually, rather than a function that depends on words_.length. Bug: 912523 Change-Id: I6afcd1a4c9c80fc0a122133fad3c825a4060b714 Reviewed-on: https://chromium-review.googlesource.com/c/1374493 Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org> Commit-Queue: Rebekah Potter <rbpotter@chromium.org> Cr-Commit-Position: refs/heads/master@{#616412} [modify] https://crrev.com/2fce4e670183180174aebc38471a3f66a8c4b1a6/chrome/browser/resources/settings/languages_page/edit_dictionary_page.html [modify] https://crrev.com/2fce4e670183180174aebc38471a3f66a8c4b1a6/chrome/browser/resources/settings/languages_page/edit_dictionary_page.js [modify] https://crrev.com/2fce4e670183180174aebc38471a3f66a8c4b1a6/chrome/test/data/webui/settings/edit_dictionary_page_test.js [modify] https://crrev.com/2fce4e670183180174aebc38471a3f66a8c4b1a6/chrome/test/data/webui/settings/fake_language_settings_private.js
,
Dec 17
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by khush...@virtusa.com
, Dec 6