wxt
wxt copied to clipboard
Content script context event
Overview
Manual Testing
Related Issue
This PR closes #<issue_number>
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...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify project configuration.
Oops did not want to assign copilot to this, could you add more context to this (haha funny coincidence) to better understand this?
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.
Every content script injection will cause this class to initiate a
window.postMessageon 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.