Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
refactor: make
inpage.js
inject itself into the MAIN world (manifes…
…t v2 only) (#22524) ## **Description** I'm working on a new build process that is primary focused on compilation speed and simplicity. The current manifest v2 way of injecting inpage.js makes that task harder. Affects manifest v2 only. This PR changes the way inpage.js is injected into the MAIN world by decoupling `inpage.js` from `contentscript.js`. This new way is very similar to the old way, except `inpage.js` now injects _itself_ into the document (MAIN world). One potential issue with this new way is that `contentscript.js` used to conditionally inject `inpage.js` into the MAIN world, but with this change the `inpage.js` file is just another "content_script". This might not be a problem though, as `inpage.js` itself checks all of the same conditions `contentscript.js` does, i.e., they both check `shouldInjectProvider()`, but the difference is that _only_ `inpage.js` decides itself if it will inject a provider into the MAIN world, whereas before it was up to both contentscript.js AND inpage.js to agree to inject the provider. To reiterate why I want to make this change: the current system requires custom logic specifically for `contentscript.js` and `inpage.js`, and inpage.js MUST complete compilation before `contentscript.js` can be start to be compiled. Additionally, `contentscript.js` needs special treatment of `fs.readFileSync` in order to inline `inpage.js` as text into itself. This complicates and slows down the build system. --- One thing this PR does NOT do is speed up the build, as I didn't change the order of compilation. `inpage.js` is still compiled before `contentscript.js`, even though `contentscript.js` no longer depends on `inpage.js`. I a) didn't know how to make this change, and b) was afraid it'd complicate an already perhaps dubious PR. --- Some things to look out for in testing: will this new way behave if the page is not an HTML doctype, is an XML/PDF document, doesn't have a `documentElement`, is on the blocked domains list, etc. --- ## **Related issues** Fixes: ## **Manual testing steps** 1. Go to any web page not on out block list 2. Open devtools in your browser 3. Type `window.ethereum` and press <enter> in the Console 4. A `Proxy` object should be logged (_not_ `undefined`) ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** - [x] I’ve followed [MetaMask Coding Standards](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/CODING_GUIDELINES.md). - [x] I've clearly explained what problem this PR is solving and how it is solved. - [ ] I've linked related issues - [x] I've included manual testing steps - [x] I've included screenshots/recordings if applicable - [x] I’ve included tests if applicable - [x] I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I’ve applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. - [x] I’ve properly set the pull request status: - [ ] In case it's not yet "ready for review", I've set it to "draft". - [x] In case it's "ready for review", I've changed it from "draft" to "non-draft". ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. --------- Co-authored-by: weizman <weizmangal@gmail.com>
- Loading branch information