wxt icon indicating copy to clipboard operation
wxt copied to clipboard

Content script context event

Open sleekslush opened this issue 5 months ago • 4 comments

Overview

Manual Testing

Related Issue

This PR closes #<issue_number>

sleekslush avatar Jun 30 '25 19:06 sleekslush

Deploy Preview for creative-fairy-df92c4 ready!

Name Link
Latest commit f24fb95c1d82740589cd8fb6d78348b7100c23fb
Latest deploy log https://app.netlify.com/projects/creative-fairy-df92c4/deploys/6862f6d0a889910008d2a438
Deploy Preview https://deploy-preview-1778--creative-fairy-df92c4.netlify.app
Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

netlify[bot] avatar Jun 30 '25 19:06 netlify[bot]

Oops did not want to assign copilot to this, could you add more context to this (haha funny coincidence) to better understand this?

Timeraa avatar Jul 24 '25 17:07 Timeraa

Oops did not want to assign copilot to this, could you add more context to this (haha funny coincidence) to better understand this?

Yea I don't care if this PR gets selected, but the problem that we're facing is this.

Every content script injection will cause this class to initiate a window.postMessage on each page load that it's whitelisted to. Our extension injects on <all_urls> for a variety of reasons. This normally isn't a huge problem, but we have encountered some customer complaints where the JS on the page is listening for window messages, checks the origin correctly, but then doesn't inspect the shape of the message itself before using it. This causes the page to basically break in a variety of cases and we have no way to disable this behavior from wxt, even when we aren't using it.

This PR is a different approach, maybe not the correct one, but basically defers removal of these event handlers to the next time the events fire. This means it's not immediate, but there's no window messaging involved and it solves the former issues I described.

If this isn't something we want to change or do, that's totally fair, but then at a minimum, we should have some way in wxt to prevent this window.postMessage behavior from happening if we aren't using the context object.

sleekslush avatar Jul 24 '25 20:07 sleekslush

Every content script injection will cause this class to initiate a window.postMessage on each page load that it's whitelisted to. Our extension injects on <all_urls> for a variety of reasons. This normally isn't a huge problem, but we have encountered some customer complaints where the JS on the page is listening for window messages, checks the origin correctly, but then doesn't inspect the shape of the message itself before using it. This causes the page to basically break in a variety of cases and we have no way to disable this behavior from wxt, even when we aren't using it.

Using postMessage also makes it easier to fingerprint the users of the extension.

One alternative would be using a custom event based on the extension ID on the window object. Websites would at least need to check for every extension by their ID separately to fingerprint users.

ion1 avatar Jul 24 '25 21:07 ion1