A contract deployment has no to. src/popup/views/approval.js:174 writes to: toAddr || "", and the wait screen renders that through toAddressHtml("") → addressTitle(""), which returns null — so the recipient line is blank rather than saying what is happening.
Pre-existing on the live showWait() path, not introduced by #201. Found by the independent review of that PR while confirming that an empty-string to does not throw; it does not, it just renders nothing.
A blank field on a screen that exists to tell the user what they are about to sign, or are waiting on, reads as a rendering fault rather than as information. Deploying a contract is also the case where the user most needs to be told that is what this is — there is no recipient to check, and the transaction creates code.
Implementation requirements
Render a contract deployment explicitly rather than as an empty recipient. Say it deploys a contract; do not print a blank, a dash, or the zero address.
Cover every screen that shows a recipient for a transaction that may lack one: the approval screen, the wait screen, and the transaction detail view if it has the same shape.
Check what addressColor("") does — the review noted it degrades to an undefined CSS color, which is harmless but should not survive into the fixed rendering.
Definition of done
A transaction with no to renders a contract-deployment label on the approval and wait screens, in full sentences per the README Language & Labeling rules.
No screen renders a blank or null recipient for such a transaction.
A transaction with a real to is unchanged.
Tests cover both cases.
TODO.md updated in the same commit.
make check passes.
A contract deployment has no `to`. `src/popup/views/approval.js:174` writes `to: toAddr || ""`, and the wait screen renders that through `toAddressHtml("")` → `addressTitle("")`, which returns `null` — so the recipient line is blank rather than saying what is happening.
Pre-existing on the live `showWait()` path, not introduced by https://git.eeqj.de/sneak/AutistMask/pulls/201. Found by the independent review of that PR while confirming that an empty-string `to` does not throw; it does not, it just renders nothing.
A blank field on a screen that exists to tell the user what they are about to sign, or are waiting on, reads as a rendering fault rather than as information. Deploying a contract is also the case where the user most needs to be told that is what this is — there is no recipient to check, and the transaction creates code.
## Implementation requirements
- Render a contract deployment explicitly rather than as an empty recipient. Say it deploys a contract; do not print a blank, a dash, or the zero address.
- Cover every screen that shows a recipient for a transaction that may lack one: the approval screen, the wait screen, and the transaction detail view if it has the same shape.
- Check what `addressColor("")` does — the review noted it degrades to an `undefined` CSS color, which is harmless but should not survive into the fixed rendering.
## Definition of done
- [ ] A transaction with no `to` renders a contract-deployment label on the approval and wait screens, in full sentences per the README Language & Labeling rules.
- [ ] No screen renders a blank or `null` recipient for such a transaction.
- [ ] A transaction with a real `to` is unchanged.
- [ ] Tests cover both cases.
- [ ] `TODO.md` updated in the same commit.
- [ ] `make check` passes.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
A contract deployment has no
to.src/popup/views/approval.js:174writesto: toAddr || "", and the wait screen renders that throughtoAddressHtml("")→addressTitle(""), which returnsnull— so the recipient line is blank rather than saying what is happening.Pre-existing on the live
showWait()path, not introduced by #201. Found by the independent review of that PR while confirming that an empty-stringtodoes not throw; it does not, it just renders nothing.A blank field on a screen that exists to tell the user what they are about to sign, or are waiting on, reads as a rendering fault rather than as information. Deploying a contract is also the case where the user most needs to be told that is what this is — there is no recipient to check, and the transaction creates code.
Implementation requirements
addressColor("")does — the review noted it degrades to anundefinedCSS color, which is harmless but should not survive into the fixed rendering.Definition of done
torenders a contract-deployment label on the approval and wait screens, in full sentences per the README Language & Labeling rules.nullrecipient for such a transaction.tois unchanged.TODO.mdupdated in the same commit.make checkpasses.