Fixes#3: Swap transactions were displaying as "Sent" or "Received" in transaction history instead of showing the actual method name (e.g. "Execute" for Uniswap swaps).
Changes
src/shared/transactions.js
When token transfers merge with normal txs in fetchRecentTransactions, preserve contract call metadata (direction, directionLabel, method, isContractCall) from the original parsed tx
src/popup/views/home.js and src/popup/views/addressDetail.js
Handle direction === "contract" when determining counterparty address for display (show the contract address, not the from address)
src/popup/views/transactionDetail.js
For contract call transactions, fetch raw input data from Blockscout and decode it using decodeCalldata from approval.js
Show decoded swap/approval/transfer details in the same style as the signing confirmation view
Show "Unknown contract call" with copyable raw hex data for unrecognized calldata
src/popup/views/approval.js
Export decodeCalldata for reuse in transaction detail view
src/popup/index.html
Add calldata display section to transaction detail view
make check output
Test Suites: 2 passed, 2 total
Tests: 14 passed, 14 total
All matched files use Prettier code style!
## Summary
Fixes #3: Swap transactions were displaying as "Sent" or "Received" in transaction history instead of showing the actual method name (e.g. "Execute" for Uniswap swaps).
## Changes
### `src/shared/transactions.js`
- When token transfers merge with normal txs in `fetchRecentTransactions`, preserve contract call metadata (`direction`, `directionLabel`, `method`, `isContractCall`) from the original parsed tx
### `src/popup/views/home.js` and `src/popup/views/addressDetail.js`
- Handle `direction === "contract"` when determining counterparty address for display (show the contract address, not the from address)
### `src/popup/views/transactionDetail.js`
- For contract call transactions, fetch raw input data from Blockscout and decode it using `decodeCalldata` from approval.js
- Show decoded swap/approval/transfer details in the same style as the signing confirmation view
- Show "Unknown contract call" with copyable raw hex data for unrecognized calldata
### `src/popup/views/approval.js`
- Export `decodeCalldata` for reuse in transaction detail view
### `src/popup/index.html`
- Add calldata display section to transaction detail view
## `make check` output
```
Test Suites: 2 passed, 2 total
Tests: 14 passed, 14 total
All matched files use Prettier code style!
```
- Preserve contract call metadata (direction, label, method) when token
transfers merge with normal txs in fetchRecentTransactions
- Handle 'contract' direction in counterparty display for home and
address detail list views
- Add decoded calldata display to transaction detail view, fetching
raw input from Blockscout and using decodeCalldata from approval.js
- Show 'Unknown contract call' with raw hex for unrecognized calldata
- Export decodeCalldata from approval.js for reuse
clawbot
requested review from sneak 2026-02-27 21:04:23 +01:00
transactions.js correctly preserves contract call metadata when token transfers merge
List views handle direction === "contract" for counterparty display
Detail view fetches raw calldata from Blockscout, decodes via reused decodeCalldata, falls back to "Unknown contract call" + raw hex
HTML additions are minimal
One minor note: displayData variable on line 185 is computed but not used (the full inputData is passed to copyableHtml instead). Not a blocker.
Assigned to sneak for merge.
Reviewed. Changes are clean and well-scoped:
1. `transactions.js` correctly preserves contract call metadata when token transfers merge
2. List views handle `direction === "contract"` for counterparty display
3. Detail view fetches raw calldata from Blockscout, decodes via reused `decodeCalldata`, falls back to "Unknown contract call" + raw hex
4. HTML additions are minimal
One minor note: `displayData` variable on line 185 is computed but not used (the full `inputData` is passed to `copyableHtml` instead). Not a blocker.
Assigned to sneak for merge.
sneak
was assigned by clawbot2026-02-27 21:04:56 +01:00
- Map known DEX methods (execute, swap, multicall, etc.) to "Swap"
label instead of raw method name like "Execute"
- Remove unused displayData variable in transactionDetail.js
Addresses review feedback on PR #10.
Known DEX methods (execute, swap, multicall, swapExactTokensForTokens, etc.) now display as "Swap" in tx lists instead of the raw method name
Removed unused displayData variable
The detail page already shows full decoded swap details via decodeCalldata → uniswap.decode(). Re-assigned to sneak.
Addressed the feedback:
1. Known DEX methods (`execute`, `swap`, `multicall`, `swapExactTokensForTokens`, etc.) now display as **"Swap"** in tx lists instead of the raw method name
2. Removed unused `displayData` variable
The detail page already shows full decoded swap details via `decodeCalldata` → `uniswap.decode()`. Re-assigned to sneak.
clawbot
removed their assignment 2026-02-27 21:08:01 +01:00
sneak
was assigned by clawbot2026-02-27 21:08:01 +01:00
The transaction detail page displays the addresses inconsistently. On one it has the color dot next to the address title, and on the other (and everywhere else) it has it next to the address itself. Please be more careful now and in the future when laying things out that you follow existing conventions. Consistency is key.
The transaction detail page displays the addresses inconsistently. On one it has the color dot next to the address title, and on the other (and everywhere else) it has it next to the address itself. Please be more careful now and in the future when laying things out that you follow existing conventions. Consistency is key.
sneak
removed their assignment 2026-02-27 21:54:56 +01:00
clawbot
was assigned by sneak2026-02-27 21:54:56 +01:00
Pushed aaeb38d: the transaction detail page now shows "Swap" (or the relevant method label) as both the page heading and a Type field for contract interactions. Previously the detail view just said "Transaction" with no type indicator.
Changes:
HTML: added tx-detail-heading id, tx-detail-type-section with Type label (hidden for regular sends/receives)
JS: render() sets heading text and type field based on direction === "contract" + directionLabel
make check passes (14 tests + prettier).
Pushed `aaeb38d`: the transaction detail page now shows "Swap" (or the relevant method label) as both the page heading and a Type field for contract interactions. Previously the detail view just said "Transaction" with no type indicator.
Changes:
- HTML: added `tx-detail-heading` id, `tx-detail-type-section` with Type label (hidden for regular sends/receives)
- JS: `render()` sets heading text and type field based on `direction === "contract"` + `directionLabel`
`make check` passes (14 tests + prettier).
clawbot
removed their assignment 2026-02-27 22:00:23 +01:00
sneak
was assigned by clawbot2026-02-27 22:00:23 +01:00
- Restructured calldata section to use same well layout as approval view:
Action label + bold name + structured details
- Always show raw data section below decoded well
- Unknown contract calls show method name in well instead of inline
Pushed 8824237 — reworked the transaction detail calldata display to match the approval view exactly:
Same well structure: border border-border border-dashed p-2 with "Action" label → bold name → structured details
Each detail: muted label on its own line, then bold value (or address dot + copyable address)
Raw data always shown below the decoded well in its own section
Unknown contract calls: method name in the Action field, raw hex below
This matches the approve-tx-decoded well in the approval view for display consistency per #3.
make check passes (14 tests + prettier).
Pushed `8824237` — reworked the transaction detail calldata display to match the approval view exactly:
- Same well structure: `border border-border border-dashed p-2` with "Action" label → bold name → structured details
- Each detail: muted label on its own line, then bold value (or address dot + copyable address)
- Raw data always shown below the decoded well in its own section
- Unknown contract calls: method name in the Action field, raw hex below
This matches the `approve-tx-decoded` well in the approval view for display consistency per #3.
`make check` passes (14 tests + prettier).
But the convention everywhere else (home, addressDetail, addressToken) is dot next to the address/ENS name, never next to a label.
Fix: remove dot from the title line, ensure it always appears next to the address or ENS name, matching the existing pattern. Pushing fix now.
Found it — in `txAddressHtml()`, the color dot is placed next to the title when a title exists:
```js
html += `<div class="flex items-center font-bold">${dot}${escapeHtml(title)}</div>`;
```
But the convention everywhere else (home, addressDetail, addressToken) is dot next to the address/ENS name, never next to a label.
Fix: remove dot from the title line, ensure it always appears next to the address or ENS name, matching the existing pattern. Pushing fix now.
Fixed — color dot now always appears next to the address/ENS name, never next to the title. Matches the convention in home, addressDetail, and addressToken views.
Fixed — color dot now always appears next to the address/ENS name, never next to the title. Matches the convention in home, addressDetail, and addressToken views.
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.
sneak
Summary
Fixes #3: Swap transactions were displaying as "Sent" or "Received" in transaction history instead of showing the actual method name (e.g. "Execute" for Uniswap swaps).
Changes
src/shared/transactions.jsfetchRecentTransactions, preserve contract call metadata (direction,directionLabel,method,isContractCall) from the original parsed txsrc/popup/views/home.jsandsrc/popup/views/addressDetail.jsdirection === "contract"when determining counterparty address for display (show the contract address, not the from address)src/popup/views/transactionDetail.jsdecodeCalldatafrom approval.jssrc/popup/views/approval.jsdecodeCalldatafor reuse in transaction detail viewsrc/popup/index.htmlmake checkoutputReviewed. Changes are clean and well-scoped:
transactions.jscorrectly preserves contract call metadata when token transfers mergedirection === "contract"for counterparty displaydecodeCalldata, falls back to "Unknown contract call" + raw hexOne minor note:
displayDatavariable on line 185 is computed but not used (the fullinputDatais passed tocopyableHtmlinstead). Not a blocker.Assigned to sneak for merge.
Quoting #3:
Addressed the feedback:
execute,swap,multicall,swapExactTokensForTokens, etc.) now display as "Swap" in tx lists instead of the raw method namedisplayDatavariableThe detail page already shows full decoded swap details via
decodeCalldata→uniswap.decode(). Re-assigned to sneak.d883ddadf2to3fd3e30f44Rebased on main (after PR #11 merge), fixed prettier formatting.
make checkpasses. Re-assigned to sneak.The transaction detail page displays the addresses inconsistently. On one it has the color dot next to the address title, and on the other (and everywhere else) it has it next to the address itself. Please be more careful now and in the future when laying things out that you follow existing conventions. Consistency is key.
Pushed
aaeb38d: the transaction detail page now shows "Swap" (or the relevant method label) as both the page heading and a Type field for contract interactions. Previously the detail view just said "Transaction" with no type indicator.Changes:
tx-detail-headingid,tx-detail-type-sectionwith Type label (hidden for regular sends/receives)render()sets heading text and type field based ondirection === "contract"+directionLabelmake checkpasses (14 tests + prettier).Pushed
8824237— reworked the transaction detail calldata display to match the approval view exactly:border border-border border-dashed p-2with "Action" label → bold name → structured detailsThis matches the
approve-tx-decodedwell in the approval view for display consistency per #3.make checkpasses (14 tests + prettier).Found it — in
txAddressHtml(), the color dot is placed next to the title when a title exists:But the convention everywhere else (home, addressDetail, addressToken) is dot next to the address/ENS name, never next to a label.
Fix: remove dot from the title line, ensure it always appears next to the address or ENS name, matching the existing pattern. Pushing fix now.
Fixed — color dot now always appears next to the address/ENS name, never next to the title. Matches the convention in home, addressDetail, and addressToken views.