* Return an estimated amount for a completed swap if an RPC provider has a delay
* Create a recursive function for updating post tx balance
* Add a few tests for the "getSwapsTokensReceivedFromTxMeta" fn
* Trigger Build
* When background port closes, UI should display a user friendly error.
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
Remove console.log
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
A couple of fixes
1. Use timeout in metaRPCClientFactory to check if UI can't
communicate with bg
2. Refactor locale setup
3. Fixed wording/capitalization
4. Fix locales usage so that linting works
5. Refactor CSS
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
do not simulate errorwq
Refactor loading css
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
Remove the onDisconnect event handler in ui as this is handled in
metarpcclientfactory
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
Do not throw in bg
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
Fix PR comments
Remove unused message 'failedToLoadMessage'
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
Move usage of locales to shared/** so that linter can see it.
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
Do not simulate error.
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
metarpc can handle multiple requests, responseHandled should be a map.
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
reload metamask button on critical error
Use metamask state (if available) to the locale, else read locale files
manually.
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
use constant and numeric separator
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
refactor error utils
remove error simulation
Memoize setupLocale function
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
test cases
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
Do not simulate error
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
1. store should be metamask state
2. code refactorings.
Tests: mock setupLocale
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
Mock fetchLocale instead
Test setup locale
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
UI/CSS changes.
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
Do not simulate failure
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
* spell MetaMask correctly
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
* Rename state to mockStore
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
* we should clean up this.responseHandled[id] in the error case.
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
* Fixed PR comments.
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
* clean up response handled.
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
Adds a new flag, `--apply-lavamoat`, to the main build script. The flag controls whether LavaMoat is actually applied to the output of the build process. The flag defaults to `true`, but we explicitly set it to `false` in the `start` package script. Meanwhile, the `start:lavamoat` script is modified such that it applies LavaMoat to the build output in development mode, but it no longer runs the build process itself under LavaMoat as there aren't very compelling reasons to do so.
This change is motivated by the fact that development builds do not have their own dedicated LavaMoat policies, which causes development builds to fail since #14537. The downside of this change is that LavaMoat-related failures will not be detected when running `yarn start`. @kumavis has plans for fixing this problem in a future major version of the `@lavamoat` suite.
* updated state on edit
* Update transaction type in updateEditableParams method instead of in the send duck
* Fix unit test
* Fix unit tests
* Fix and improve unit tests
Co-authored-by: dragana8 <dragana.simic@consensys.net>
The phishing warning page URL environment variable has been renamed
from `PHISHING_PAGE_URL` to `PHISHING_WARNING_PAGE_URL`. We call this
page the "phishing warning page" everywhere else, and this name seemed
better suited (it's not a phishing page itself).
The variable has been listed and documented in `.metamaskrc.dist` as
well.
An externally hosted phishing warning page is now used rather than the
built-in phishing warning page.The phishing page warning URL is set via
configuration file or environment variable. The default URL is either
the expected production URL or `http://localhost:9999/` for e2e testing
environments.
The new external phishing page includes a design change when it is
loaded within an iframe. In that case it now shows a condensed message,
and prompts the user to open the full warning page in a new tab to see
more details or bypass the warning. This is to prevent a clickjacking
attack from safelisting a site without user consent.
The new external phishing page also includes a simple caching service
worker to ensure it continues to work offline (or if our hosting goes
offline), as long as the user has successfully loaded the page at least
once. We also load the page temporarily during the extension startup
process to trigger the service worker installation.
The old phishing page and all related lines have been removed. The
property `web_accessible_resources` has also been removed from the
manifest. The only entry apart from the phishing page was `inpage.js`,
and we don't need that to be web accessible anymore because we inject
the script inline into each page rather than loading the file directly.
New e2e tests have been added to cover more phishing warning page
functionality, including the "safelist" action and the "iframe" case.
* Update version parsing to allow rollback release
When we want to rollback a release on Chrome, sometimes we use the
fourth part of the version for the rollback release. This is because
the Chrome web stores does not directly allow rolling back, but instead
requires us to re-submit the release we want to roll back to with a
higher version number.
The manifest version parsing now allows for a fourth version part.
The comments have also been updated to be more descriptive, and to fix
a minor inaccuracy.
* Fix typo in comment
Co-authored-by: David Walsh <davidwalsh83@gmail.com>
Co-authored-by: David Walsh <davidwalsh83@gmail.com>
Adds a new flag, `--apply-lavamoat`, to the main build script. The flag controls whether LavaMoat is actually applied to the output of the build process. The flag defaults to `true`, but we explicitly set it to `false` in the `start` package script. Meanwhile, the `start:lavamoat` script is modified such that it applies LavaMoat to the build output in development mode, but it no longer runs the build process itself under LavaMoat as there aren't very compelling reasons to do so.
This change is motivated by the fact that development builds do not have their own dedicated LavaMoat policies, which causes development builds to fail since #14537. The downside of this change is that LavaMoat-related failures will not be detected when running `yarn start`. @kumavis has plans for fixing this problem in a future major version of the `@lavamoat` suite.
Zachary Belford
Daniel
Olusegun Akintayo
ryanml
Ariella Vu
Erik Marks
George Marshall
Guillaume Roux
Frederik Bolding
Dan J Miller
benlwyre
Jyoti Puri
Brad Decker
Mark Stacey
Lachlan Tweedie
Hassan Malik
Niranjana Binoy
Alex Donesky
kumavis
Shane
David Walsh
Hennadii Ivtushok