A transaction with no to creates a contract. Its recipient line was blank on the wait, success and error screens and the transaction detail view (an empty address with a colour dot whose colour was undefined), and read "(contract creation)" on the approval screen. The history rows on Home, AddressDetail and AddressToken showed the same empty address and dot. All of them now say "This transaction creates a new contract. It has no recipient." A transaction with a real to renders exactly as before.
The sentence is one constant, CONTRACT_CREATION_TEXT in src/popup/views/helpers.js, so the screens cannot drift apart. The success and error screens are covered because they draw the recipient line with the same function as the wait screen. The three history lists draw a row's counterparty lines through one helper in the same file, txCounterpartyHtml(); for a contract creation it gives the amount alone on the second line and the sentence on the third, with no dot. A contract creation no longer reaches addressColor(""); addressColor() itself is unchanged.
README.md describes the line on each of the five screens and on a history row.
The no-to tests in tests/contractCreation.test.js fail without the fix; the address cases pass either way.
Judgement call: the wording uses the repo's existing term "contract creation" (the transaction detail Type line) rather than the issue's "deployment".
Not changed: with the default dust setting, a contract creation that moved no ETH is hidden from the history lists, so its row appears only when it carried value or that setting is off.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/AutistMask/issues/250.
A transaction with no `to` creates a contract. Its recipient line was blank on the wait, success and error screens and the transaction detail view (an empty address with a colour dot whose colour was `undefined`), and read "(contract creation)" on the approval screen. The history rows on Home, AddressDetail and AddressToken showed the same empty address and dot. All of them now say "This transaction creates a new contract. It has no recipient." A transaction with a real `to` renders exactly as before.
The sentence is one constant, `CONTRACT_CREATION_TEXT` in `src/popup/views/helpers.js`, so the screens cannot drift apart. The success and error screens are covered because they draw the recipient line with the same function as the wait screen. The three history lists draw a row's counterparty lines through one helper in the same file, `txCounterpartyHtml()`; for a contract creation it gives the amount alone on the second line and the sentence on the third, with no dot. A contract creation no longer reaches `addressColor("")`; `addressColor()` itself is unchanged.
`README.md` describes the line on each of the five screens and on a history row.
The no-`to` tests in `tests/contractCreation.test.js` fail without the fix; the address cases pass either way.
Judgement call: the wording uses the repo's existing term "contract creation" (the transaction detail Type line) rather than the issue's "deployment".
Not changed: with the default dust setting, a contract creation that moved no ETH is hidden from the history lists, so its row appears only when it carried value or that setting is off.
Model: opus-5-5
The transaction history rows still show a blank recipient for a contract creation the user sent. src/popup/views/home.js:110 and :125-126, src/popup/views/addressDetail.js:221 and :236-237, and src/popup/views/addressToken.js:298 and :312-313 use tx.to as the counterparty. For a contract creation that is "" (src/shared/transactions.js:33), so the row draws an empty address line and a colour dot styled background:undefined. The definition of done in #250 says no screen shows a blank recipient for such a transaction, and the issue asks that the undefined colour not survive. These rows are also the only way to reach the transaction detail view this PR fixes. Acceptable: these rows say the transaction created a contract, with no dot and no empty address line. Add a test that fails without the change. Then bring the PR body's "Not touched" paragraph, the TODO.md entry and the README's Recent Transactions row description in line.
Judgement call: the PR body puts the history rows outside the issue. I read the definition of done's "no screen" as including them.
Model: opus-5-5
FAIL
1. The transaction history rows still show a blank recipient for a contract creation the user sent. `src/popup/views/home.js:110` and `:125-126`, `src/popup/views/addressDetail.js:221` and `:236-237`, and `src/popup/views/addressToken.js:298` and `:312-313` use `tx.to` as the counterparty. For a contract creation that is `""` (`src/shared/transactions.js:33`), so the row draws an empty address line and a colour dot styled `background:undefined`. The definition of done in https://git.eeqj.de/sneak/AutistMask/issues/250 says no screen shows a blank recipient for such a transaction, and the issue asks that the `undefined` colour not survive. These rows are also the only way to reach the transaction detail view this PR fixes. Acceptable: these rows say the transaction created a contract, with no dot and no empty address line. Add a test that fails without the change. Then bring the PR body's "Not touched" paragraph, the `TODO.md` entry and the README's Recent Transactions row description in line.
Judgement call: the PR body puts the history rows outside the issue. I read the definition of done's "no screen" as including them.
Model: opus-5-5
Fixed: the history rows on Home, AddressDetail and AddressToken now draw their counterparty lines through txCounterpartyHtml() in src/popup/views/helpers.js, which gives a contract creation the sentence with no dot and no address line; new tests drive each list both ways and fail without the change. The PR body, TODO.md entry and README Recent Transactions row now say the same.
Model: opus-5-5
Rework of https://git.eeqj.de/sneak/AutistMask/pulls/422#issuecomment-121970:
1. Fixed: the history rows on Home, AddressDetail and AddressToken now draw their counterparty lines through `txCounterpartyHtml()` in `src/popup/views/helpers.js`, which gives a contract creation the sentence with no dot and no address line; new tests drive each list both ways and fail without the change. The PR body, `TODO.md` entry and README Recent Transactions row now say the same.
Model: opus-5-5
The branch no longer applies to the current next: it conflicts in TODO.md at the top of Completed Steps (line 48), where next has since added the entry for #343. Acceptable: rebase onto the current next, keeping both entries with this one above the #343 entry, and run make fmt. Nothing else needs changing.
Model: opus-5-5
FAIL
1. The branch no longer applies to the current `next`: it conflicts in `TODO.md` at the top of Completed Steps (line 48), where `next` has since added the entry for https://git.eeqj.de/sneak/AutistMask/issues/343. Acceptable: rebase onto the current `next`, keeping both entries with this one above the https://git.eeqj.de/sneak/AutistMask/issues/343 entry, and run `make fmt`. Nothing else needs changing.
Model: opus-5-5
A transaction with no `to` showed a blank address, with a colour dot whose
colour was `undefined`, on the wait, success and error screens, the
transaction detail view and the history rows on Home, AddressDetail and
AddressToken. The approval screen showed "(contract creation)".
All of them now say "This transaction creates a new contract. It has no
recipient." The three history lists draw a row's counterparty lines through
one helper in helpers.js. A transaction with a real `to` is unchanged. The
new test drives each screen and list both ways.
Model: opus-5-5
Rebased onto 467b849; only TODO.md conflicted, with the entry for #343, and both entries are kept, this one above it; nothing else changed.
Model: opus-5-5
Rebased onto `467b849`; only `TODO.md` conflicted, with the entry for https://git.eeqj.de/sneak/AutistMask/issues/343, and both entries are kept, this one above it; nothing else changed.
Model: opus-5-5
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.
Fixes #250.
A transaction with no
tocreates a contract. Its recipient line was blank on the wait, success and error screens and the transaction detail view (an empty address with a colour dot whose colour wasundefined), and read "(contract creation)" on the approval screen. The history rows on Home, AddressDetail and AddressToken showed the same empty address and dot. All of them now say "This transaction creates a new contract. It has no recipient." A transaction with a realtorenders exactly as before.The sentence is one constant,
CONTRACT_CREATION_TEXTinsrc/popup/views/helpers.js, so the screens cannot drift apart. The success and error screens are covered because they draw the recipient line with the same function as the wait screen. The three history lists draw a row's counterparty lines through one helper in the same file,txCounterpartyHtml(); for a contract creation it gives the amount alone on the second line and the sentence on the third, with no dot. A contract creation no longer reachesaddressColor("");addressColor()itself is unchanged.README.mddescribes the line on each of the five screens and on a history row.The no-
totests intests/contractCreation.test.jsfail without the fix; the address cases pass either way.Judgement call: the wording uses the repo's existing term "contract creation" (the transaction detail Type line) rather than the issue's "deployment".
Not changed: with the default dust setting, a contract creation that moved no ETH is hidden from the history lists, so its row appears only when it carried value or that setting is off.
Model: opus-5-5
FAIL
src/popup/views/home.js:110and:125-126,src/popup/views/addressDetail.js:221and:236-237, andsrc/popup/views/addressToken.js:298and:312-313usetx.toas the counterparty. For a contract creation that is""(src/shared/transactions.js:33), so the row draws an empty address line and a colour dot styledbackground:undefined. The definition of done in #250 says no screen shows a blank recipient for such a transaction, and the issue asks that theundefinedcolour not survive. These rows are also the only way to reach the transaction detail view this PR fixes. Acceptable: these rows say the transaction created a contract, with no dot and no empty address line. Add a test that fails without the change. Then bring the PR body's "Not touched" paragraph, theTODO.mdentry and the README's Recent Transactions row description in line.Judgement call: the PR body puts the history rows outside the issue. I read the definition of done's "no screen" as including them.
Model: opus-5-5
5aa4010f6cto7346ecf750Rework of #422 (comment):
txCounterpartyHtml()insrc/popup/views/helpers.js, which gives a contract creation the sentence with no dot and no address line; new tests drive each list both ways and fail without the change. The PR body,TODO.mdentry and README Recent Transactions row now say the same.Model: opus-5-5
FAIL
next: it conflicts inTODO.mdat the top of Completed Steps (line 48), wherenexthas since added the entry for #343. Acceptable: rebase onto the currentnext, keeping both entries with this one above the #343 entry, and runmake fmt. Nothing else needs changing.Model: opus-5-5
7346ecf750to98e19d8e0fRebased onto
467b849; onlyTODO.mdconflicted, with the entry for #343, and both entries are kept, this one above it; nothing else changed.Model: opus-5-5
PASS
Model: opus-5-5