MetaMask / MetaMask/metamask-mobile
content-script lacks tests required to ensure stability and accuracy
- Dominant language
- TypeScript
- Stars
- 3k
- Forks
- 1.7k
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 669
Description
### What is this about?
## Context
The [inpage bridge content-script](https://github.com/MetaMask/metamask-mobile/blob/main/scripts/inpage-bridge/content-script/index.js) is a file that the application injects into the various webpages visited within the in-app browser. The moment that the file is included in its javascript environment, it immediately executes while analyzing that the page meets the required criteria for the MetaMask provider to be injected.
## Problem
Despite this file playing a key role in determining if MetaMask is able to work on a page, we lack the necessary tests to ensure it's stability and functional accuracy. As described in [#8675](https://github.com/MetaMask/metamask-mobile/pull/8675#issuecomment-2009675540) it is not straightforward to test this file due to the fact that it will execute it's code the moment it gets imported (see [code](https://github.com/MetaMask/metamask-mobile/blob/ffc7225c952ce7a25ae25782e6a87c49fec41680/scripts/inpage-bridge/content-script/index.js#L3-L6)). This means that in a test file, it will attempt to run it's logic prior to the developer being able to set up the necessary mocks required to mock out the window object.
## Potential Solutions
**Simple Solution**
An initial solution would be to refactor the content-script to _not_ execute as soon as it is imported into a javascript environment. Instead, it should be imported, and require an explicit functional call in order for it to be run. This is the approach taken by extension who exports a [shouldInjectProvider](https://github.com/MetaMask/metamask-extension/blob/5ff6215d735b97aeb6e870442e2ca8d2d7612ac5/shared/modules/provider-injection.js#L6-L13) that is later called explicitly. This allows for the provider to be explicitly tested as seen in extension [here](https://github.com/MetaMask/metamask-extension/blob/5ff6215d735b97aeb6e870442e2ca8d2d7612ac5/shared/modules/provider-injection.test.ts).
Likewise, SDK takes an [even more modular approach](https://github.com/MetaMask/metamask-sdk/blob/331f73a7e2170204435755fdae46d4a7f6dc8b15/packages/sdk/src/utils/shouldInjectProvider.ts#L1-L23) of abstracting out each function used to determine if the provider should be injected or not. This allows for even more precise testing of the logic.
@NicolasMassart suggested that if we take a similar approach, we can instead invoke the function explicitly in one of the WebView callbacks once the page has loaded (e.g onMessage).
**Ideal solution**
As this code is duplicated in Extension, Mobile, and SDK, an ideal solution would be to pull this into a single package that is then imported in used across all our products. This would simplify the process and eliminate each team needing to maintain this code individually.
### Scenario
_No response_
### Design
_No response_
### Technical Details
_No response_
### Threat Modeling Framework
_No response_
### Acceptance Criteria
_No response_
### Stakeholder review needed before the work gets merged
- [X] Engineering (needed in most cases)
- [ ] Design
- [ ] Product
- [ ] QA (automation tests are required to pass before merging PRs but not all changes are covered by automation tests - please review if QA is needed beyond automation tests)
- [ ] Security
- [ ] Legal
- [ ] Marketing
- [ ] Management (please specify)
- [ ] Other (please specify)
### References
_No response_
Contributor guide
Research direction
Start by reading scripts/inpage-bridge/content-script/index.js, especially the import-time execution described in the issue, then review the linked provider-injection.test.ts example. Determine which provider-injection behavior needs coverage and how explicit invocation should work; done means the content script can be tested with window mocks and stability and accuracy are covered by tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- testing, web-dev
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100