event_entryproperties fullfilled with login data in chrome

[Timbalu]

Hi everybody

Simply I never really use the automatic log-in function which saves the data.
But now I did, since a few weeks, and was really surprised, to find the plain login-name and the -password being asterixed set in the backends entryform part of entryproperties in the freetags tag input field and the latter in the properties password input field.

This does happen with Chrome only, FF does not do this!

Is that a funny configuration (meaning strange plugin order or so) or is that a code and/or browser issue?
Please set me on the right track! Does anybody has the same appear?

[garvinhicking]

Hi!

Yes, because the field is called "password" some browser try to be smarty and autofill it.

I think we have patched this already to include autocomplete="off" in that field, haven't we? Then I would wonder why it doesn't work....

[Timbalu]

It's a 1.7.2...

Isn't that need to be "namespaced" somehow...?
I think this is bad to happen there, since you could miss to purge them before submitting a new entry.

When was that fixed?

[garvinhicking]

I don't remember. Can you check if autocomplete="off" or sth like that is contained in the input field for the passwort?

[Timbalu]

YES, element html copy:
<input autocomplete="off" class="input_textbox" type="password" name="serendipity[properties][entrypassword]" value="">

The value field is shown asterixed.

What makes me wonder why this happens, since this input has a (unique?) name....


In addition the input field where the name is displayed.
<input type="text" name="serendipity[properties][freetag_tagList]" id="properties_freetag_tagList" class="wickEnabled input_textbox" value="" style="width: 100%">

[garvinhicking]

Hi!

I figure then it's because of the type='password' thing. If autocomplete is there, I don't really know how to prevent chrome from autofilling.

(The name is filled I believe simply becuause it's the next username field next to a password...)

[Timbalu]

Well then... maybe our "template director" (YL) has an idea on how to get rid of it...

[yellowled]

Sure. Don't use browser autofill. Ever.

YL

[Timbalu]

I appreciate Mr. Green, ... but this is not a good answer for John Doe, isn't it?

[yellowled]

Actually, it is very good advice for John Doe in my book.

Anyway, I don't see an option. If the autocomplete attribute fails, the only option would be to not use the password type here, which very likely is not what we want.

Also, if it only fails in Chrome, it's very likely a browser bug. You could report it to the Chromium project, but fixing it in our markup sounds not very reasonable to me.

YL

[Timbalu]

Actually, it is very good advice for John Doe in my book.

Oho, are you working on a "S9y for Dummies" equivalent to that hadley bestseller...?

Could you give a hint on where to do this in detail? I did not see a config option for this on my first quick view...

Edit: A found it, some last update must have reset my extended option view. It is in Options - extended view - passwords and formulas...

[yellowled]

http://www.chromium.org/for-testers/bug ... guidelines

Although I'm not entirely sure as to how this might develop once Chrome switches to the Blink engine …

YL

[Timbalu]

I dropped my edit the same time you dropped you post I assume... Thanks for the hint.

I played with it for a while now and it seems the shown fullfilled values are my piwik ones... not the Serendipity login - which was quite equal though, that is why I did not notice.
Chrome had a forbidden rule for http://domain.ext/serendipity/serendipity_admin.php in the management screen for passwords, but since this didn't work obviously, I purged that. Now I wanted to put that in again, but I don't know how to do this, since it just links to a help page not being helpful on that specific topic.... Maybe I need to reset them all to make that work again... Anyone has experiences with that?