No announcement yet.
  • Filter
  • Time
Clear All
new posts

  • #16
    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


    • #17
      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.
      Last edited by andyx1975; 15th Nov 2017, 00:40.


      • #18
        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


        • #19
          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..


          • #20
            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 )
            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,


            • #21
              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.