Login input detection

[jonaaix]

I actually didn't find yet how the login input field detection works. I would be open to contribute some improvements.
There are a couple of sites, where the login field is not recognized, especially if it is behind a modal.

• instagram.com
• twitter.com
• soundcloud.com
• songsterr.com

You can comment more, if you have the issue.

[RoelVB]

Sometime you have to "redetect fields" using the right-click menu or the keyboardshortcut.
I've tested this with Instagram and Twitter and it works fine.

I appreciate you wanting to contribute. This is how the detection flow is now:
The content_script calls the detectFields() method after the page is loaded:

ChromeKeePass/src/content_script.ts

Lines 6 to 8 in 6826fdf

	$(document).ready(()=>{
	pageControl.detectFields();
	});

Then the PageControl class tries to find credential fields:

ChromeKeePass/src/classes/PageControl.ts

Lines 27 to 67 in 6826fdf

	public detectFields()
	{
	const fieldSets: FieldSet[] = [];
	let passwordFields: JQuery<HTMLElement> = $('input[type="password"]');
	if(passwordFields.length) // Found some password fields?
	{
	passwordFields.each((passwordIndex, passwordField)=>{ // Loop through password fields
	let prevField: JQuery<HTMLElement>;
	$('input').each((inputIndex, input)=>{ // Loop through input fields to find the field before our password field
	const inputType = $(input).attr('type') || 'text'; // Get input type, if none default to "text"
	if(inputType != 'password') // We didn't reach our password field?
	{
	if($(input).is(':visible') && (inputType === 'text' || inputType === 'email' || inputType === 'tel')) // Is this a possible username field?
	prevField = $(input);
	}
	else if($(input).is($(passwordField))) // Found our password field?
	{
	if(prevField) // Is there a previous field? Than this should be our username field
	{
	fieldSets.push(new FieldSet(this, $(passwordField), prevField));
	return; // Break the each() loop
	}
	else if($(input).is(':visible')) // We didn't find the username field. Check if it's actually visible
	{
	fieldSets.push(new FieldSet(this, $(passwordField)));
	return; // Break the each() loop
	}
	else // We didn't find a visible username of password field
	return;
	}
	});
	});
	}
	// Remember the fields we've found
	this._fieldSets = fieldSets;
	this._findCredentials();
	this._attachEscapeEvent();
	}

[jonaaix]

https://www.tchibo.de/bettwaesche-grau-p402011966.html#modal-productimagegallery-modalGalleryImage-401449333

The input field has attribute autocomplete="off" but ChromeKeepass detects it as login input

[RoelVB]

A field with autocomplete="off" could be a login field, so I'm not sure if we should ignore this.
Maybe make it optional in next version?

[jonaaix]

I'm currently collecting all issues I'm running into, to be sure to have most edge cases covered when improving the detection. I could also imagine to use machine learning technologies here to accurately detect the correct input fields.

[RoelVB]

Twitter and Instagram should work fine in the next update.
Because of a24141f

[jonaaix]

Probably we can use a MutationOberserver instead of interval checks. Seems to be widely supported so far. But I think it will require some performance tests.

https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver
https://caniuse.com/mutationobserver

[RoelVB]

That's a great idea. Luckily it's already in the dev branch (it's going to be in the next release) 😉
I did some performance tests and it has literally no CPU load worth mentioning, but there will still be an option to disable it.

I tested on a couple af sites with livechats, because they update all the time. But the extensions CPU load stayed at 0.0%.

[jonaaix]

Sounds great!
I think where it could create issues are sites, that have a lot of DOM interaction because they are rendered via JavaScript using Angular, React or OpenGL. You could also try those sites:

• https://threejs.org/examples/#webgl_instancing_performance
• https://material.angular.io/components/categories
• Facebook
• Airbnb

[jonaaix]

Unfortunately the plugin recognized this field as login input and filled in the values, but I was editing a wordpress user profile, and the prefilled values got saved.

Probably we can disallow larger forms in the detection, and I would not use autocomplete="off" as single detection criterion. Or alternatively if it is the single criterion, then disallow the prefill.

[RoelVB]

It's going to be hard to detect "larger forms", because a lot of modern sites don't use <form>-tags anymore. So what defines a form?
In your example we could say the table contains a few input fields, which could make it a "larger form", but this could break detection on other sites where there's a lot of/all content in a table. It's hard to imagine now, but there are still some older sites around that are build entirely with tables in tables, next to tables. Because bang in the day is was the easiest way to get your layout the same in all the different browsers.

Is it really a problem that the field is detected incorrectly? I guess it's problematic when you have "automatically fill single credentials" enabled.

But... I would like a future version to have an option to blacklist/whitelist sites or even fields on sites.

[jonaaix]

Currently I think the most convenient way would be to keep the fact, that most sites would use the correct input types type="email" and type="password" and probably have some login related wording (.*pass.*, .*user.*, .*mail.*, ...) in the input ids. But I see this is very difficult to predict. So having a validated growing dataset with columns of attribute names and values, tree distance to the corresponding other login inputs, would help in finding a pattern. I'm pretty sure that for each site there can be multiple different conditions fulfilled for login inputs. Then we can use a threshold of n conditions that must be fulfilled, and use different quantifier for the conditions (necessary and sufficient).
And finally I think there will always be some sites, that will need a manual selection. Some AdBlockers also use this method of defining explicit elements.