Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: make inpage.js inject itself into the MAIN world (manifest v2 only) #22524

Merged
merged 25 commits into from
Feb 8, 2024

Conversation

davidmurdoch
Copy link
Contributor

@davidmurdoch davidmurdoch commented Jan 12, 2024

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 in the Console
  4. A Proxy object should be logged (not undefined)

Screenshots/Recordings

Before

After

Pre-merge author checklist

  • I’ve followed MetaMask Coding Standards.
  • I've clearly explained what problem this PR is solving and how it is solved.
  • I've linked related issues
  • I've included manual testing steps
  • I've included screenshots/recordings if applicable
  • I’ve included tests if applicable
  • I’ve documented my code using JSDoc format if applicable
  • I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.
  • I’ve properly set the pull request status:
    • In case it's not yet "ready for review", I've set it to "draft".
    • 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.

Copy link
Contributor

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

@davidmurdoch
Copy link
Contributor Author

Added team-security label to check out the reintroduction of web_accessible_resources.

Copy link
Member

@weizman weizman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given some of my notes, we should discuss how to proceed

@davidmurdoch davidmurdoch marked this pull request as draft January 14, 2024 19:56
@davidmurdoch davidmurdoch changed the title refactor: inject inpage.js as a script src in manifest v2 refactor: make inpage.js inject itself into the MAIN world (manifest v2 only) Feb 3, 2024
@davidmurdoch davidmurdoch force-pushed the refactor-inject-inpage branch 2 times, most recently from 2358cc2 to 0072a28 Compare February 5, 2024 19:01
@davidmurdoch davidmurdoch changed the title refactor: make inpage.js inject itself into the MAIN world (manifest v2 only) refactor: make inpage.js inject itself into the MAIN world (manifest v2 only) Feb 5, 2024
Copy link

codecov bot commented Feb 5, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (65f5b81) 68.45% compared to head (9ae02ae) 68.45%.
Report is 3 commits behind head on develop.

Additional details and impacted files
@@           Coverage Diff            @@
##           develop   #22524   +/-   ##
========================================
  Coverage    68.45%   68.45%           
========================================
  Files         1089     1089           
  Lines        42902    42902           
  Branches     11428    11428           
========================================
  Hits         29368    29368           
  Misses       13534    13534           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@brad-decker
Copy link
Contributor

@davidmurdoch they are precise but not accurate, if in general over the course of many builds the value is higher then it represents an actionable issue.

@metamaskbot
Copy link
Collaborator

Builds ready [e5f2b68]
Page Load Metrics (798 ± 25 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint96138111115
domContentLoaded12271942
load7229017985325
domInteractive12271942
Bundle size diffs
  • background: 0 Bytes (0.00%)
  • ui: 0 Bytes (0.00%)
  • common: 0 Bytes (0.00%)

Copy link
Member

@kumavis kumavis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the history of inpage.js goes back to the beginning of time so it's possible browsers have changed their behavior that motivated the current setup. I believe our reasonings included:

  • inpage.js execution timing. our current setup was the only way we found to run before page code did
  • ability to modify the page globalThis to add the api. I thought contentscript couldn't do this, only modify the DOM.
  • clear separation of security sensitive (content script) and non-sensitive (inpage.js)
  • bundle factoring inpage should be a single bundle and not factored into multiple files

some of your changes here may not have affected the above

@davidmurdoch
Copy link
Contributor Author

davidmurdoch commented Feb 6, 2024

@kumavis

inpage.js execution timing. our current setup was the only way we found to run before page code did

its the same set up, but inpage.js now injects itself.

ability to modify the page globalThis to add the api. I thought contentscript couldn't do this, only modify the DOM.

inpage.js now modifies the DOM to inject itself into the DOM so it can modify globalThis

clear separation of security sensitive (content script) and non-sensitive (inpage.js)

they are now more separated, as contentscript.js doesn't depend on inpage.js now(and visa versa)

bundle factoring inpage.js should be a single bundle and not factored into multiple files

no changes here

development/build/scripts.js Show resolved Hide resolved
development/build/scripts.js Outdated Show resolved Hide resolved
development/build/scripts.js Show resolved Hide resolved
@metamaskbot
Copy link
Collaborator

Builds ready [a83bff8]
Page Load Metrics (807 ± 38 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint761591102211
domContentLoaded95523136
load7129568077938
domInteractive95523136
Bundle size diffs
  • background: 0 Bytes (0.00%)
  • ui: 0 Bytes (0.00%)
  • common: 0 Bytes (0.00%)

development/build/utils.js Outdated Show resolved Hide resolved
development/build/utils.js Outdated Show resolved Hide resolved
Copy link
Member

@weizman weizman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good, few notes to discuss ☝️

davidmurdoch and others added 2 commits February 7, 2024 10:56
Co-authored-by: weizman <weizmangal@gmail.com>
Co-authored-by: weizman <weizmangal@gmail.com>
@metamaskbot
Copy link
Collaborator

Builds ready [2861767]
Page Load Metrics (732 ± 17 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint781209395
domContentLoaded9191521
load6548017323617
domInteractive9191521
Bundle size diffs
  • background: 0 Bytes (0.00%)
  • ui: 0 Bytes (0.00%)
  • common: 0 Bytes (0.00%)

@metamaskbot
Copy link
Collaborator

Builds ready [9ae02ae]
Page Load Metrics (810 ± 25 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint81171103209
domContentLoaded9401673
load7298978105125
domInteractive9401673
Bundle size diffs
  • background: 0 Bytes (0.00%)
  • ui: 0 Bytes (0.00%)
  • common: 0 Bytes (0.00%)

development/build/utils.js Show resolved Hide resolved
@davidmurdoch davidmurdoch merged commit ba3a20f into develop Feb 8, 2024
78 checks passed
@davidmurdoch davidmurdoch deleted the refactor-inject-inpage branch February 8, 2024 19:22
@github-actions github-actions bot locked and limited conversation to collaborators Feb 8, 2024
@metamaskbot metamaskbot added the release-11.12.0 Issue or pull request that will be included in release 11.12.0 label Feb 8, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
release-11.12.0 Issue or pull request that will be included in release 11.12.0 team-extension-platform team-security
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants