Why My Chrome Extension Filled Input Values but Nothing Appeared on Screen

Extension auto-fill works on most vendor sites, but fails on Angular-based page (ng-pristine vs ng-dirty issue)

Problem Background

We are building a browser extension that auto-fills customer information (first name, last name, email, phone number, address, etc.) into different vendor websites. Each vendor site has different page structures, and our content script is responsible for detecting input fields and filling data automatically.

Issue Symptom

Most vendor sites work correctly.

However, on one specific vendor site, auto-fill does not work:

• Our logs show values are being filled
• No visible changes appear in the UI
• Input fields remain empty from user perspective

Filling input: firstName = John
Filling input: email = test@example.com

But UI still shows no updated values.

Environment

• Extension: Chrome Extension (content script)
• Language: JavaScript
• Target site: Vendor web application
• Framework (discovered later): Angular

Debugging Process

We used DevTools to inspect the page:

• Checked DOM structure
• Traced content script execution
• Compared working vs non-working vendor pages

We discovered the page is built using Angular, and each input field has multiple internal states:

• ng-pristine
• ng-dirty

We realized:

• Our script was targeting the ng-dirty input element
• But the visible UI input was ng-pristine element

So the value was being set on a non-visible or inactive Angular binding layer.

Root Cause

Angular maintains multiple internal representations of form inputs. ng-pristine and ng-dirty represent different internal form states.

Our selector matched the wrong internal DOM representation instead of the actual visible input element.

Fix

We updated our selector strategy:

• Avoid relying on Angular state classes (ng-pristine, ng-dirty)
• Always target the actual visible input element
• Prefer stable selectors like:
  • input[name]
  • input[id]
  • input[formcontrolname]

We also ensured proper value update with correct input/change event dispatch.

Additional Debugging Tips for Web Automation

When building browser extensions or web automation tools, a common issue is that a script appears to fill an input successfully, but nothing is visible on the page.

Before assuming the value assignment failed, verify that you are interacting with the actual visible element.

1. Check Computed Style

An element may exist in the DOM but still be hidden from users.

const style = getComputedStyle(input);

console.log({
  display: style.display,
  visibility: style.visibility,
  opacity: style.opacity
});

Common indicators of hidden elements:

• display: none
• visibility: hidden
• opacity: 0

2. Check Element Size

Some frameworks render placeholder elements that have no visible size.

const rect = input.getBoundingClientRect();

console.log({
  width: rect.width,
  height: rect.height
});

If width or height is 0, the element may not be visible or interactable.

3. Check offsetParent

A quick visibility check is:

if (input.offsetParent === null) {
  console.log("Element is not visible");
}

In many cases, a null offsetParent indicates the element or one of its parent containers is hidden.

4. Verify the Active Element

Sometimes multiple inputs exist for the same field. Frameworks may keep hidden inputs, template inputs, or detached DOM nodes.

Always verify:

• The element is visible
• The element is attached to the current DOM tree
• The element receives focus correctly
• The element is the one users actually interact with

5. Save the Page for Offline Debugging

One of the most useful debugging techniques is to save the page locally:

1. Open the page in Chrome
2. Select "Save Page As"
3. Choose "Web Page, Complete"
4. Open the saved HTML file locally

This creates a reproducible debugging environment and allows you to inspect the DOM structure without repeatedly navigating through the vendor application.

This technique is especially useful when debugging browser extensions, Angular applications, React applications, and complex enterprise web portals

Conclusion

• Angular forms can have multiple internal state layers for the same input
• Do not rely on framework-specific state classes for automation
• Always target the actual visible input element
• Saving full page locally is a powerful debugging technique

❤️ Support This Blog

---

If this post helped you, you can support my writing with a small donation. Thank you for reading.

---

Coffee ☕ Thanks 🙏 Extra Support ❤️