Some notes from recent time I spent trying to improve the detection of form submission events, for posterity / anyone interested in why it doesn’t work for 100% of websites / anyone that wants to contribute some new code to the extension.
Idea 1: Read data from the/a form after web page has navigated away from current page
We have event listeners attached to forms already until they detect a form submission so if we are unloading the page or navigating to a new SPA view and those event listeners are still present, we can try invoking them (or some variant of them) and be able to show the “Save entry” button.
The current browser extension APIs (e.g. WebExtensions) do not permit us to access the information needed directly but there are a few possible ways we could combine information from multiple sources to decide that a sign in operation has taken place:
-
DOM beforeunload event handler (listen from content script)
Fires for many reasons, including user pressing the back button and other events that are unlikely to be suitable triggers for offering to save a password. -
browser.webNavigation.onHistoryStateUpdated() (listen from background script)
Would require us to message the content script to get the relevant form information. There is no guarantee that we will be able to find the relevant form when that message arrives, nor be able to correlate the request with any continuously cached form data.
Idea 2: Intercept calls to form.submit() from the page script
This is conceptually much simpler than idea 1 because there is a clear indication from the web page that a form submit will occur (events won’t fire and even validations can’t stop it). However, it can never capture sign-ins that are written purely in JavaScript and avoid all form submission methods.
The implementation is at least as complex though. It would basically be a similar idea to how Kee communicates with Kee Vault running in a page script context and we’d then monkey patch the form.submit function (potentially on the form prototype). Since we don’t control the script context of other websites, we could hit some road blocks such as frameworks (or other extensions?) that attempt a similar monkey patch operation.
Draft risk assessment:
- Form index may have changed / been deleted before content script gets notified. Minimal risk since page could just click a submit button for some other form anyway so can’t pollute user data fields any more than before.
- Page could DOS user by triggering many form submit messages. No risk since no different than what it could it trigger anyway before.
- Other addons could listen to the message. No risk since they would have to be able to inject content scripts to this page anyway.
Future
Between the two ideas, I suspect we’d be able to capture 99.99% of sign-in operations. We don’t know how many we currently capture but it’s most likely less than 99% so this could bring big improvements.
I’m not planning to spend any more time on these ideas for the foreseeable future and will instead give some thought to whether it is a good idea / possible to also offer another “backup” entry saving mechanism that doesn’t depend on detecting a completed submission event. In the mean time, the “backup” of adding the entry manually to Kee Vault or KeePass is still as valid as it always has been.