Selectors API sometimes ignores ":-webkit-autofill" pseudo-class
Reported by
davidsve...@hotmail.com,
May 24 2018
|
|||||||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.56 Safari/537.36
Steps to reproduce the problem:
Have a classic login form with enabled autocomplete (default) with some little page load time (meaning no static HTML on local disk).
Try to use ":-webkit-autofill" in both CSS and JS.
What is the expected behavior?
Obviously to ":-webkit-autofill" work correctly on script-side.
What went wrong?
While in case of CSS selector with ":-webkit-autofill" works correctly all the time, in case of JavaScript Chrome returns different results.
Difference is that calling document.querySelector(':-webkit-autofill') or myInputElement.matches(':-webkit-autofill') sometimes returns positive results (element or true, respectively), but another times it returns negative results (no elements found, false).
This is quite confusing and happens randomly (wasn't able to tell what it depends on) - few times in row after refresh it's okay, then not...).
Last funny thing is that I tried to bypass it by applying css rule like
input:-webkit-autofill { position: relative; }
Which (again) was applied correctly all the time, however in case of calling getComputedStyle(myInputElement).getPropertyValue('position') result was "static".
Baffling.
Did this work before? N/A
Chrome version: 67.0.3396.56 Channel: beta
OS Version: 10.0
Flash Version: Shockwave Flash 29.0 r0
,
May 24 2018
,
May 28 2018
Could you change your script to force updating layout tree? e.g. Adding |document.body.offsetHeight|. It seems |SelectorQuery| class runs with dirty style values. :-webkit-autofill is implemented in - HTMLFormControlElement::SetAutofilled() - SelectorChecker::CheckPseudoClass() which checks HTMLFormControlElement::IsAutofilled()
,
May 29 2018
,
May 29 2018
@Reporter: Could you please try to test the issue as suggested in comment# 3 and report back us the behaviour, hence adding Needs-Feedback label. Thanks!
,
May 29 2018
,
May 29 2018
Alright, will try it tomorrow and report back.
,
May 29 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 30 2018
As per comment#7 adding Needs-feedback label and waiting for reporter's response on this issue. Thanks!
,
Jun 7 2018
Sorry, I totally forgot about this issue because of work. But could you please better describe what to do with "document.body.offsetHeight"? Calling it updates layout tree? Problem is, right now, there is no reliable way to reproduce issue (as I mentioned, happens only sometimes), so what should I exactly observe?
,
Jun 7 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 8 2018
As the issue seems to be out of scope for triaging it from our end hence adding few Devs from "UI>Browser>Autofill" team to CC list and requesting to help in triaging it further. Thanks!
,
Jul 17
As per comment#12 adding label "TE-NeedsTriageHelp" and requesting someone from "UI>Browser>Autofill" team to have a look into this and help in further triaging it. Thanks! |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by sindhu.chelamcherla@chromium.org
, May 24 2018