Thanks for the report. This is an interesting case. Adding dvadym@, because sites immune to filling are bad for password generation. I have not understood the root cause yet, this is what I observed:

* Even trying to save the password forcibly (chrome://flags/#enable-password-force-saving) failed, the logs show that the recorded password is empty, while DevTools console for the field from which I triggered force-saving shows a non-empty value.

* When I saved the password via Import (chrome://flags/#password-import-export) instead, I could reproduce what sergiu@ is reporting: the lock icon is present, signalling a saved password being ready to fill, but:
  - no autofill
  - no way to get even the password filled on demand (dvadym@ -- should this work from any password field?)

It's quite tricky page from Password Manager perspective:
 1.There is no <form> element
 2.username/password doesn't have id/name attributes
The problem is that support of empty id/names are implemented only for <form> elements: GetUnownedAutofillableFormFieldElements function knows nothing how such elements are handled in PasswordManager. But here is the problem also that, if we there are no id/name then we can't know which exactly elements should be filled. So probably the best solution is to implement fill on account select for password fields.

Autofilling works.