Feature request: user-defined rules to support unsupported sites

[NicolasWebDev]

Hi,

Right now, I frequently use some unsupported sites, which give me the error "Error: No fillable forms available for fields: login, secret". More than a failure in browserpass, it is more a failure of those websites which do not follow best practices.

Instead of supporting all those websites, or supporting all the websites mentioned in #62, it would be nice to have a mechanism to define site-specific rules to indicate the fields that should be filled by browserpass.

E.g. it could be a yaml document that lets us configure the CSS selector to find the user and the password input fields.

[maximbaz]

Absolutely, I don't think it's possible to get away from doing something like you suggest. #62 serves more like a check to see whether we are missing some patterns (e.g. a bunch of websites identifying login field in a specific way), but most often it's just site-specific issues which can't be fixed with the current infrastructure we have in the extension.

When it comes to finding a solution for this, I think it would be worth checking all existing issues, where we could see different use-cases. For example, helping browserpass identify password field on a "broken" website is one thing, teaching browserpass how to fill out AWS account ID or credit card or address is another. How to share site-specific workarounds (whether it's reviewed and merged into extension, or crowdsourced and shared on wiki, or whatever) might influence some architectural decisions about this. I think there was also an issue linking to some third-party project that already contains a bunch of domain-specific workarounds.

I can tell you that nobody has been actively interested to look deeper in this topic and propose a solution, so if you feel passionate about it, please do not hesitate to dive into this topic!

[NicolasWebDev]

Thanks for sharing your thoughts, @maximbaz. I completely understand that this may not be a top priority at the moment, but I appreciate the insights you've provided. It does seem like an important feature to grow the project that hasn't been explicitly addressed in the existing issues list.

Perhaps a phased approach could work well—starting with support for the most common use cases and then extending functionality over time to accommodate more complex scenarios (e.g., AWS account IDs or credit card details), while avoiding breaking changes. Maybe extending a yaml configuration format would work.

I’d love to contribute to this effort, but unfortunately, due to some family commitments, I won’t be able to dive into this topic in the near future.