Email filled by SimpleLogin disappears after Privacy card autofill; manual edit prevents it

[thunder-detector]

Summary

On multiple shopping checkouts, an email alias filled using SimpleLogin disappears when I subsequently use the Privacy extension's card Autofill. Editing the email field before running Privacy Autofill prevents the clearing.

Environment

• SimpleLogin by Proton: Secure Email Aliases: 3.0.7
• Privacy | Protect Your Payments: 2.4.17
• Brave: 1.95.101 on macOS 27.0 (26A428)
• Both extensions are enabled with access to all sites.

Steps to reproduce

1. Open a shopping checkout with an email field and card payment fields.
2. Fill the email address using SimpleLogin.
3. Use Privacy's card Autofill.
4. Observe that the previously populated email field becomes empty.

Expected: Filling the payment fields preserves the email address.

Actual: The email field is cleared. This has occurred on multiple merchant checkouts. An exact merchant URL and a minimal public reproduction are not available in this report; the checkout platform has not been confirmed.

Successful workaround / comparison

1. Fill the email using SimpleLogin.
2. Type one extra letter into the email field, then delete that letter so the address is unchanged.
3. Press Tab to leave the field.
4. Use Privacy's card Autofill.

With this extra edit-and-blur step, the email stays populated. This result was confirmed interactively by the affected user; it is not an automated test.

Suspected cause from source review

In the public source at commit d18b40fc774a3b477468bc608c3589a24f04c3ed (which declares version 3.0.7), the inline SimpleLogin button handler ends with inputElem.value = res.alias and does not dispatch an input or change event:

src/content_script/input_tools.js, lines 167–186

One possibility is that a checkout displays the assigned DOM value while its internal form state remains empty. A later update during payment autofill could then restore the empty value. The successful manual edit-and-blur comparison supports investigating this path.

This is a hypothesis, not a confirmed runtime trace. The installed extension bundle has not been compared byte-for-byte with the public source, and the precise SimpleLogin fill entry point has not yet been isolated. Other autofill extensions have not been disabled for an isolated reproduction.

Could the inline fill path be checked for compatibility with checkout form state, including the appropriate bubbling input/change notifications and framework-compatible value updates?

No email aliases, card details, account data, or checkout session URLs are included in this report.

[thunder-detector]

Proposed fix, with regression evidence

This appears related to #229. Credit to @old4ever for the existing native-setter/event-dispatch approach. I tested that PR's current content script (8deab167a01206f153f6a18f77c57005eaab8145) alongside unmodified master and a compact equivalent patch. I propose completing #229 to address this path.

The change is to replace the direct inputElem.value = res.alias assignment with a helper that updates the native value, notifies form listeners, and performs actual focus/blur:

setInputValue(input, value) {
  const view = input.ownerDocument.defaultView;
  const valueSetter = Object.getOwnPropertyDescriptor(
    view.HTMLInputElement.prototype,
    "value"
  ).set;

  input.focus();
  valueSetter.call(input, value);
  input.dispatchEvent(new view.Event("input", { bubbles: true }));
  input.dispatchEvent(new view.Event("change", { bubbles: true }));
  input.blur();
},

Then call InputTools.setInputValue(inputElem, res.alias) in handleOnClickSLButton. The native prototype comes from the input's own document. The existing PR also passes the tests below; this compact version is supplied for review, not as a claim of a new approach.

Tests completed

The attached harness executes the full content script, stubs background messaging with a fixed .invalid alias, and clicks the actual SimpleLogin button. It then changes another checkout state value to force a render. It tests React 18.3.1 controlled inputs, ordinary forms listening for bubbling input, and ordinary forms listening for bubbling change, each in the page world and a separate Chromium isolated world.

Source	Six fixture/world combinations
Master d18b40fc774a3b477468bc608c3589a24f04c3ed	Email clears after the simulated payment-state update in all six.
Existing PR #229	Email retained in all six; form state, input/change notifications, and actual focus/blur assertions pass.
Compact patch	Same passing results in all six.

18 cases passed, including expected baseline failures. The manual edit-and-Tab workaround also passed four controls on React and ordinary input-listener forms. The modified script passes Prettier 2.6.2 formatting/parser checks.

Environment: Playwright 1.62.1, Chromium 151.0.7922.34, macOS. Page network requests were blocked. The bundle includes the patch, harness, pinned source snapshots, local React bundles/licenses, and per-case results.

Limitations: these are synthetic checkouts with simulated payment-state updates, not a test of Privacy itself or the affected merchant. No full extension build or Firefox/Safari testing was performed. The results support this fix for the missing form-state notification, but do not yet prove it resolves every instance of the reported interaction.

simplelogin-autofill-fix-and-tests.zip

[thunder-detector]

@nguyenkims, this report appears related to #229. We’ve attached a reproducible test bundle confirming that its current fix preserves the email across six form scenarios. Could you review the evidence and advise whether #229 is ready to move forward?