Issue metadata
Sign in to add a comment
|
Onblur gets fired every time a response comes back from the server if there is a hidden password control on the page and a password saved for that domain.
Reported by
sarah.l....@gmail.com,
Dec 20 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.108 Safari/537.36 Steps to reproduce the problem: 1. Setup a domain where you have a saved password for it and host the AutofillLoop.html file that can found in the attached zip. 2. Go to the AutofillLoop.html page and look at the developer tools What is the expected behavior? This should show Log in the console only after an onblur of the 'test' textbox has happened, which should be only a few (1 or 2) times on the load of the page. What went wrong? Instead you should see that Log gets constantly printed to the console (see gif). This is because every time we get a response from the server it causes another onblur to the 'test' textbox, which sends it in a loop forever. Did this work before? Yes Not 100% sure but our customers have only reported this since moving to 63 Does this work in other browsers? Yes Chrome version: 63.0.3239.108 Channel: stable OS Version: 10.0 Flash Version: This only happens if you have a password saved for that domain and if the password textbox is set to display:none. If the textbox is visible then the issue won't occur. If you have no saved password for the domain, the issue won't occur. I have included another html file in the zip, which is to try and get it to prompt to save your password, however I haven't had great success with this in Chrome or Opera. Sometimes it will prompt but mostly it won't. It does however always work in Edge and Firefox. This looping behaviour only occurs if we send a request to the server. If that piece of code is removed everything works as expected. Previous to Chrome 63 the onblur event of the textbox was not fired when returning from the server.
,
Dec 20 2017
,
Dec 20 2017
,
Dec 21 2017
Unable to reproduce this issue on reported version 63.0.3239.108 using Windows 10 with steps mentioned below. 1. Extracted AutofillLoop.zip and opened prompt to save.html and gave credentials and clicked submit -- observed Your file was not found error 2. Now opened AutofillLoop.html and opened devtools console. 3. Observed no continuous loop of Log file. So clicked inside text box and clicked outside of box and observed one log entry and error. Attaching screenshot for reference. @Reporter: Could you please check the scrennshots and let us know if we miss anything. And please provide sample URL or test file to check the issue. Thanks!
,
Dec 21 2017
Are you hosting the .html file on a site? Or are you just opening it via double clicking? It mentions the file:/// protocol in that screenshot so I'm assuming it was opened via double clicking from File Explorer. This issue is only reproducible if you have a saved password for the domain that the html page is running under. I don't believe Chrome ever prompts you to save a password when running a page via file:///. As I mentioned in step 1, if possible, you should host that html file on a site that you have a saved password for. This is the quickest way to get a repro. Alternatively you could use IIS and point it to a folder with those two html files in. If you do this then you will need to go to the PromptToSave.html page first and try get Chrome into a situation where it will prompt you to save your password. This is the bit I found hit and miss but is necessary to reproduce the issue. I'm not sure what circumstances Chrome will prompt you to save your password but that repro set worked in all other browsers for prompting to save the entered password. Hope that helps!
,
Dec 21 2017
Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 22 2017
I have uploaded the files here https://battre.github.io/bug-796563/PromptToSave.html I can reproduce this with Chrome 63 but it seems fixed in Chrome 64 Beta. I don't expect that there will be any pushes to Chrome 63 over the holiday break so I am not sure we can do anything but wait.
,
Dec 22 2017
Could you please confirm that it is fixed for you for version 64 as well?
,
Dec 22 2017
Unable to reproduce this issue on reported version 63.0.3239.108 with link given in comment#7 with steps mentioned below. 1. Navigated to https://battre.github.io/bug-796563/PromptToSave.html and gave some texts in two fields and clicked on submit. 2. It navigated to another URL, Now opened dev console and observed no log entries. Clicked outside box and observed one log entry. Attaching screencast for reference @battre: Please check the video and let us know if we miss anything. @Reporter: You can check the issue on latest beta build 64.0.3282.39. You can download latest beta build from https://www.chromium.org/getting-involved/dev-channel. Thanks!
,
Dec 22 2017
This is how I reproduced: 1. Go to https://battre.github.io/bug-796563/PromptToSave.html 2. Fill username and password 3. Click on key icon in omnibar and save password 4. Submit form
,
Dec 22 2017
I have tested in Chrome 64.0.3282.39 and I can confirm that the issue no longer happens. I managed to reproduce it in Chrome 63 using the github link @battre provided and it no longer repeatedly logs in Chrome 64. I have also tested our original scenario that our customers were experiencing and it seems to be fixed. Thanks for looking into it!
,
Dec 22 2017
Thank you. Then let's wait for the M64 release. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by dtapu...@chromium.org
, Dec 20 2017