Bugs caused by autofill, paste, and browser extensions

A customer cannot check out. The Pay button stays grey. Support asks them to try again, and it works fine on the support agent's machine. The ticket is closed as "cannot reproduce".

The customer used their password manager. It filled the email field, the browser never fired the event the form listens to, and the form still believed the field was empty.

Nobody typed anything wrong. The tester just typed, and real users rarely do.

Short version

• Autofill can fill a field without the app noticing, so validation stays stuck.
• Password managers also fill hidden fields and fields you did not mean them to touch.
• Pasted text carries formatting, invisible characters, and trailing spaces.
• Ad blockers and privacy extensions block requests your app depends on.
• Always confirm an extension bug twice: once with extensions on, once in a clean profile.

---

Why this whole category gets missed

Testers are careful people. Careful people click into a field and type each character. That path fires a keydown event, then an input event, then a change event, and every framework notices.

Real users take other paths:

• The browser offers a saved address and they click it.
• A password manager fills email and password in one keystroke.
• They copy an order number from an email and paste it.
• They use a mobile keyboard that inserts a whole word at once.

Some of these paths skip events. Some insert content you never expected. Your form was only ever tested on the typing path.

---

Part 1: Autofill

Autofill is when the browser or a password manager puts saved values into a form for you.

There are two separate things doing it, and they behave differently:

• Browser autofill, built into Chrome, Safari, Firefox, and Edge. It fills addresses, cards, and contact details.
• Password manager extensions, such as 1Password, Bitwarden, or LastPass. They fill logins and sometimes much more.

Test both. They fail in different ways.

Set up before you test

You need saved data first, or autofill has nothing to offer. In Chrome, open chrome://settings/addresses and add an address for "Sara Ahmed, 14 Oak Lane, Manchester, M1 4TR". Open chrome://settings/payments and add a test card, 4111 1111 1111 1111. Then install a password manager and save a login for https://staging.example.com with [email protected].

Test A: The button that stays disabled

1. Open the signup or checkout form.
2. Click the email field and pick the autofill suggestion. Do not type.
3. Look at the submit button.

If the button stays disabled while every field is visibly full, you have the bug from the opening story. It usually means the app checks a value on keyup and never on change.

Confirm it cleanly: after autofilling, click into the email field and press the spacebar then backspace. If the button suddenly becomes active, the values were fine all along and only the event was missing. Put that detail in the report, because it points the developer straight at the cause.

Test B: The validation that reappears

1. Autofill the whole form.
2. Click Submit.
3. Watch for messages like "Email is required" under a field that clearly contains an email.

Same root cause, different symptom. Some forms show both.

Test C: Hidden and wrong fields

Password managers guess. They look at field names and labels, and they are often wrong.

Things to check:

• A hidden field, such as a referral code or a honeypot field used to catch spam bots, gets filled. If the app rejects submissions when the honeypot has a value, real users get blocked.
• A "Company name" field gets filled with the username.
• A search box on the page gets filled with an email address.
• The card number goes into a "Reference" field on an invoice form.

Open DevTools, search the Elements panel for type="hidden", then autofill and check whether any of those values changed.

Test D: Autofill on multi-step forms

Step 1 collects an address, step 2 collects a card. Autofill step 1, click Next, then click Back. Common bugs: the fields are empty again, the fields are full but the app thinks they are empty, or autofill fires twice and appends the address to itself, producing 14 Oak Lane14 Oak Lane.

Test E: The yellow background

Browsers style autofilled fields with their own background colour. On a dark theme with white text, an autofilled field can end up white text on pale yellow. Screenshot it in both light and dark mode.

---

Part 2: Paste

Pasting looks harmless. It is not.

How to test paste properly:

1. Paste plain text. Baseline.
2. Paste text with a trailing space. Copy 10432 including the space. Check whether the app trims it.
3. Paste formatted text from a word processor into every rich text field, then compare with Ctrl + Shift + V, which pastes without formatting.
4. Paste an emoji and a non-Latin character, such as 名前, into name fields.
5. Paste more text than the field allows. A 500-character limit should cut or warn, not silently accept 2000.
6. Paste into a field that blocks paste, such as "Confirm email". It should not throw Uncaught TypeError: Cannot read properties of null (reading 'value') in the console.
7. Drag and drop text into a field. Same events as paste on some browsers, different on others.

Invisible characters deserve attention. A zero-width space or a non-breaking space looks like nothing on screen but breaks an exact-match search. If a lookup fails and the value looks correct, check the character count against what you expect.

Bad: The app stores "10432 " and the search for 10432 returns nothing.

Good: The app trims whitespace on input, and the search works.

---

Part 3: Browser extensions

A typical user runs three to eight extensions. Each one can inject scripts, block requests, and rewrite the page before your app finishes loading.

The extensions that cause the most trouble

• Ad and privacy blockers (uBlock Origin, Privacy Badger, Ghostery). They block requests by URL pattern. Anything with analytics, track, ads, pixel, or metrics in the path is a target.
• Password managers. See the autofill section above.
• Translation extensions. They rewrite text nodes, which breaks apps that read text back out of the page.
• Dark mode extensions. They invert colours and can make text unreadable.
• Grammar checkers (Grammarly). They add their own elements inside your text boxes and can interfere with editors.

The failures they cause

The classic one: your app loads a payment or chat widget from a third-party domain. An ad blocker blocks it. The container is there, the widget never arrives, and the page shows a spinner forever. The console shows net::ERR_BLOCKED_BY_CLIENT, which means the browser blocked it, not the server. If you see that string, an extension is responsible.

Another one: your own analytics call is blocked, and the code after it never runs because the promise rejects and nothing catches it. A blocked tracking call should never stop a checkout.

How to test it in twenty minutes

1. Create a clean Chrome profile with no extensions. Call it "QA Clean".
2. Create a second profile with the five most common extensions installed. Call it "QA Real World".
3. Run your main flows in both. When something breaks in "QA Real World", disable extensions one at a time to find the culprit, then record the extension name and version in the bug report.

You can also simulate the blocking without installing anything. In DevTools, open Network, right-click a request such as https://cdn.example-analytics.com/track.js, and choose Block request URL. Reload. If the page dies, an ad blocker will kill it for real users too.

Telling the two apart

Before you file, answer one question: does it also fail in the clean profile?

• Fails in both profiles. A normal product bug. Report it without mentioning extensions.
• Works clean, fails with extensions. An extension conflict. Still your bug if the extension is common.
• Fails clean, works with extensions. Rare. Usually a caching difference, so retest both.

An extension conflict is a real ticket. "The user should turn off their ad blocker" is not a fix your product team can ship.

Because these bugs depend on the exact browser, profile, and extension set, the environment section of the report does most of the work. Tools like Crosscheck capture the browser version, screen size, console errors, and blocked network requests along with the screenshot, which removes the usual back and forth about what the reporter had installed.

---

Frequently asked questions

Should I test with a password manager or just browser autofill?

Both, because they behave differently. Browser autofill is more predictable. Extension managers fill more fields, sometimes fields you did not expect, and they run at different moments during page load.

Is it fair to log a bug caused by someone else's extension?

Yes, if the extension is common. uBlock Origin has tens of millions of users. If your checkout breaks for them, that is your problem to solve, usually by loading the blocked script in a way that failure does not stop the flow.

How do I know if the app missed the autofill event or the value never arrived?

Look at the field. If you can see the value on screen, the value arrived and the app missed the event. If the field is empty, autofill did not match the field at all, which is a different fix involving the field's name and autocomplete attributes.

Do these bugs appear on mobile too?

Yes, and often worse. Mobile keyboards with autocorrect and word prediction insert whole words at once, which behaves more like paste than typing. Test at least one flow on a real phone, not only in the browser's device simulator.

How many extensions should my test profile have?

Five is enough: one ad blocker, one password manager, one grammar checker, one dark mode extension, and one you know your customers use. More than that makes it hard to work out which one caused a failure.