[Blama]

Hi andyx1975,

how does the login page relate to your normal application and the problems you discuss in #1?
I only have the annoying password manager in my User Administration Form (and there it also does not steal focus (under Windows)). All other forms are fine. Do you have your focus-lost problem in the whole application?

Best regards
Blama

[andyx1975]

Hi Blama

Yes it is in the whole application... the DateRangeItem is just an example. It also appears in DynamicForms... the method "form.setAutoFocus(true)" does not really work... just sometimes most of the times you see that the focus is set and went lost apr. 1 second after the form is drawn. As far as I can see is that this appears on all spots where any fieldItem requests a focus.

[andyx1975]

okay another question let us say... I use a plain HTML Page and make after a successful login a forwarding to antother html page with the smartGWT application. Does this really work?

Under my domain I am running a smartgwt application and a redmine system. Chrome can not distinguish both systems from each other... the password manager refers only to the domain and ignores the underlying HTML pages. For example page:

Smartgwt: https://mydomain/application/myApplication.html
Redmine: https://mydomain/redmine/redmine.html

For example:
- I login into redmine and store the entered user and passwort into the chrome password manager
- Then I open the smartgwt url
- The stored redmine user and passwort will be inserted automatically into the smartgwt application

I guess the workaround with a plain html page will not work here since chrome passwords are stored by domain.

best wishes
Andy

[Isomorphic]

While we still recommend a separate, plain HTML login page for all the reasons given in the QuickStart, unfortunately you are correct, it doesn't provide a workaround for this Chrome/Linux bug. Federated authentication where authentication takes place at another domain would, but obviously that's a larger change and not appropriate for many applications.

So at this moment there are no known workarounds. This is the third very bad bug to hit Chrome in the past weeks, hopefully this is not a new trend..

[tomas1lamr]

Hi Guys!

we are facing the same issue with built-in password manager. We decided to disable it. However, chrome ignore autocomplete="off" completely.
Is there any way how to set autocomplete attribute on TextItem and PasswordItem with string value? I fail in doing that. And textItem/passwordItem has only setAutoComplete method that has as value NATIVE, NONE.

When I modify DOM (in browser directly), and use "nope" for text input and "new-password" the built in password manager is not triggered in chrome anymore. (see https://gist.github.com/runspired/b9...4418dea35718fe )
Would it be possible extend the api to support these values?
Is there any way how I can set it from sgwt not? Or with some js? I'm trying to setAttribute("autocomplete","nope") it does nothing unfortunately.

Thank you,
T

[Isomorphic]

That's a clever hack.

Probably the best approach to changing the DOM yourself would be to use the SmartClient AutoTest APIs via JSNI within GWT.

Since this Chrome bug is affecting lots of users, we'll consider adding a bogus value to the AutoComplete enum just to enable this hackaround.

[Isomorphic]

We've added a new attribute FormItem.autoCompleteKeywords in both the 12.0 and 11.1 branches, which will allow you to provide the "nope" value and others in order to solve the described issue. Please try the next nightly build, dated Nov 30 or above.

Regards
Isomorphic Software

[Isomorphic]

Note that a new Chrome Bug has been filed (by tomas1lamr?) since the Chrome dev working on the original bug mentioned in Post #14 thought that it was a separate issue. Anyone here affected should probably star the new issue to give it more attention.

[Isomorphic]

A second, JavaScript-based workaround has been posted here by user firewire33. Thanks firewire!

[andyx1975]

Google has now fixed this issue. You can store passwords again and you do not loose the focus. I tested this on Chorme 64 (Ubuntu). Worked!