Three More Real-World Auto-Fill Bugs We Found While Building a Chrome Extension
Yesterday we fixed an issue where our auto-fill engine was targeting invisible input elements instead of the actual visible fields.
After deploying that fix, we continued testing across multiple vendor websites and discovered three additional issues. None of them were particularly complicated, but all three caused auto-fill failures in real-world scenarios.
This is a good reminder that browser automation is often less about complex algorithms and more about handling the countless variations of web forms.
Background
We are building a Chrome extension that automatically fills customer information such as:
First Name
Last Name
Email Address
Phone Number
Address
Province
Postal Code
The extension works across multiple vendor websites, each built with different technologies and UI frameworks.
During testing, we discovered the following issues.
Issue #1: document.querySelector Only Returns the First Match
Initially, our code used:
document.querySelector(selector);
to locate target inputs.
This worked on many websites but failed on some pages that contained multiple matching elements.
For example:
<input name="address" hidden>
<input name="address">
The first element matched the selector but was hidden.
Because querySelector() only returns the first matching element, our auto-fill logic stopped there and never reached the visible input.
Fix
Instead of using:
document.querySelector(...)
we switched to:
document.querySelectorAll(...)
and then filtered the results to locate the actual visible and interactive element.
This significantly improved reliability across websites with duplicated inputs.
Issue #2: Address Keyword Matched Email Address
Our auto-fill engine identifies fields using keyword matching.
For address fields, we search for keywords such as:
However, we discovered an unexpected overlap.
The word "address" appears inside the phrase:
Email Address
As a result, some email inputs were incorrectly classified as physical address fields.
This produced behaviors such as:
Fix
Before performing address matching, we normalize and exclude email-related labels.
Examples:
Email Address
Email
E-mail Address
are first recognized as email fields and removed from address matching logic.
This eliminated the conflict.
Issue #3: Select Inputs Require Option Values Instead of Display Text
Text inputs are relatively straightforward.
Select inputs are more complicated.
Consider a province selector:
<select>
<option value="BC">British Columbia</option>
<option value="AB">Alberta</option>
</select>
The user sees:
British Columbia
but the actual value expected by the form is:
BC
Our original implementation attempted to set:
select.value = "British Columbia";
which failed because no option existed with that value.
Fix
Instead of matching against display text only, we first locate the correct option and then assign its underlying value:
select.value = "BC";
After dispatching the appropriate change event, the form behaved correctly.
Lessons Learned
Building browser automation for multiple websites is rarely about writing the auto-fill logic itself.
Most of the effort goes into handling edge cases:
The more websites we support, the more variations we encounter.
In many cases, the solution is not complex. The challenge is simply discovering the root cause through careful debugging and testing.
Every vendor site teaches us something new about how web forms are actually implemented in the real world.
❤️ Support This Blog
If this post helped you, you can support my writing with a small donation.
Thank you for reading.
Comments
Post a Comment