I am not sure if this is a feature or a bug, but whenever I open the page with combo box with the focus on I get “helpful suggestion” pertaining to user name and password, this is totally wrong, the combo box is serving the purpose of selecting some entries. I have few web pages using combo box control and all get me the same grievance. Is there a way to stop Xojo from giving the wrong suggestion?
I use Mac and Safari for testing but this should be irrelevant in this case.
You can play with the HTML control autocomplete options by running javascript like this:
[Edit: this works for normal fields, but for a combobox, see code below…]
Event WebPage1.Shown()
dim js as string = _
"var u = document.getElementById('" + EditField1.ControlID + "_field" + "'); " + _
"u.autocomplete='off'; "
self.ExecuteJavaScript(js)
See How to turn off form autocompletion - Security on the web | MDN
I believe that browsers also look at the name of the field, so if you have a field named ‘user’ or ‘password’ the browser will try to be helpful and do autofill.
Is a browser feature. In this case the browser ‘thinks’ the field is a login/password field, that could be something that Xojo may look into depending on the code conditions.
Can you create a sample project that shows this browser issue, open a ticket on Issues and mention what os and browser are you using?
Correction, for a ComboBox the code is slightly different (using _input instead of _field for the proper ID)
Event Combobox1.Shown()
dim js as string = _
"var u = document.getElementById('" + me.ControlID + "_input" + "'); " + _
"u.autocomplete='off'; "
self.ExecuteJavaScript(js)
Or as a one-liner:
Event Combobox1.Shown()
self.ExecuteJavaScript("document.getElementById('" + me.ControlID + "_input').autocomplete='off';")
Mike;
I have tried the java script that you have posted, I use Mac M1 and Safari, Xojo2024R1. The <autocomplete=‘off’> shows in the inspect element in the browser but that does not change the behavior of the combo box. It is still suggesting to choose user name. I have placed the java script under Shown event, using _input.
According to this StackOverflow post, no web browser has respected autocomplete=off in password fields since 2014.
What is the name of the field? Are there other username / password fields nearby? Safari is doing it’s best to guess, so you have to help it figure out the field isn’t for logging in.
It “should” work, but I’ve not tested it with a combobox. Another idea would be to fully clear the caches for 127.0.0.1 - I wonder if Safari might be remembering that you had autocompleted that field in the past, and is now overriding the autocompete='off' setting?
Go to Safari / Settings / Manage Website Data and enter the IP in the search field:
Further reference material from MDN, to complement Tim’s post:
Modern browsers implement integrated password management: when the user enters a username and password for a site, the browser offers to remember it for the user. When the user visits the site again, the browser autofills the login fields with the stored values.
Additionally, the browser enables the user to choose a master password that the browser will use to encrypt stored login details.
Even without a master password, in-browser password management is generally seen as a net gain for security. Since users do not have to remember passwords that the browser stores for them, they are able to choose stronger passwords than they would otherwise.
For this reason, many modern browsers do not support
autocomplete="off"for login fields:
- If a site sets
autocomplete="off"for a<form>, and the form includes username and password input fields, then the browser still offers to remember this login, and if the user agrees, the browser will autofill those fields the next time the user visits the page.- If a site sets
autocomplete="off"for username and password<input>fields, then the browser still offers to remember this login, and if the user agrees, the browser will autofill those fields the next time the user visits the page.
You can try setting the autocomplete attribute’s value to “new-password”, but even that isn’t guaranteed to work the way you want in any browser as they may ignore it or offer to generate a password.
Well, the combo box control is called CustodianPopup - so no resemblance with the password/login whatsoever. I have tried to change the name of the control, it didn’t make any difference.
I have no problem ignoring this nuisance on my machine but once the web app is posted on the server it is a different story. Of course the audience for this web app is limited and is using different browser, still it is a nuisance which I would like to avoid if possible that is.
Oh, and just to clarify further, the combo box control serves the purpose of selecting custodian name from the list, typing in few chars limits the available options in the list reducing need for scrolling (this works). I have few pages using combo boxes for similar selections.
Something in your setup is triggering the browser to see the ComboBox as part of a login form. At the heart of the ComboBox is an HTML <input> element, so the browser performs the same detection there as it would if you were using a TextField, we just need to figure out what’s causing it. I can replicate the autocomplete suggestion here with a simple test where I have a ComboBox and a password field on the same page. Does that match your setup?
Another idea: what if you delete all “other passwords for 127.0.0.1…” ? You can do that in Safari / Settings / Passwords…
As the browser is trying to ‘guess’ if the combobox is a login element, it relies not only on the name of the control but also the label next to it or other controls. Is difficult to know what triggers the browser to do this but is not only the name of the combobox.
The only way I’ve found to get the ComboBox to not offer autocomplete suggestions in Safari when on a page with a password field is by putting it in a WebContainer. Simply parenting it to a different control doesn’t do the trick when I used a WebRectangle. I suspect it’s a depth measure in Safari.
Confirmed. Safari seems to be measuring relative depths. You can disable the login autocomplete on the ComboBox in Safari if you embed the password field within two other parent controls. In this case, I used WebRectangles. It looks awful in design, but it works:
You can then set the style of the two rectangles to remove the borders.
EDIT: Example project
Anthony,
Thanks for your suggestion, I will try. Just as FYI, the web app has separate login page where the user is required to enter name/pswd, I don’t mind having autocomplete there.
Also, I can’t just delete the password in the chain as I need to test the web app and each time I do it on my machine the login/pswd is needed. It is just distracting as Safari tries to “help” on combo box on other web pages.
Anthony;
I saw your sample project, it appears to do exactly what I would like to happen. The login page in my web app has user/pswd input fields (along with labels) on the WebPagePanel.
Still I don’t quite understand why combo box placed on separate web page would be interfered by login page. I will try to modify the login page and see if that makes difference. Thanks again.
I have placed combo box in the WebRectangle, made the rectangle big enough with the Has Background Color turned off. This appear to prevent the Safari from showing “helpful” password prompt. Only problem now is the border of the rectangle, I don’t see any attributes making it transparent in Xojo IDE.
If you look at the Shown events for the WebRectangles in the project I provided, you’ll see how to disable the borders in the browser. You cannot (and should not ever be able to) turn them off for the design view of the IDE or you’ll not be able to see them.
Any reason why you don’t use the Opening event in this case? or just playing it safe.
Either way works. Shown is the default event when you add an event handler for WebRectangles, so that’s where I added it. It’s just showing you what you can do.
