diff options
Diffstat (limited to 'docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md')
| -rw-r--r-- | docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md | 92 |
1 files changed, 2 insertions, 90 deletions
diff --git a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md index 335b3d3..be52da9 100644 --- a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md +++ b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md @@ -179,9 +179,9 @@ taking that too literally. | 112 | Toggle unread on a whole thread cannot reach "all unread" on a partly-read thread | defect | S | open, found 2026-08-17. A toggle over a UNION has no direction on a mixed thread | | 113 | No way to see a message's HTML source | information | S | open, 2026-08-17. Chromium's own View source cannot work here; needs our own plain-text dialog. Item 100 removed the dead entry, which was an overreach: the user had not asked for it | | 114 | Save image is offered on every image and does nothing | defect | S | open, found 2026-08-17 by right-clicking a real image. No `downloadRequested` handler exists anywhere, so the request is emitted and never answered | -| 115 | A copy from the message pane gives no confirmation | presentation | XS | open, 2026-08-17. Copy link address, Copy image address and Copy image all work, silently. `statusMessage` already exists and already expires | +| 115 | A copy from the message pane gives no confirmation | presentation | XS | **done** 2026-08-19, unreleased. Four entries report, each naming what it copied; connected to the page's own QActions, so the entry is covered wherever it is triggered from | | 116 | Copy image copies markup instead of the image | defect | XS | **dropped** 2026-08-17, same day. NOT A DEFECT: `wl-paste --list-types` run immediately after a copy reports `image/png`, `application/x-qt-image` and 30 more image flavours. The clipboard is correct and Chromium is behaving. The earlier "text only" reading was taken minutes late off a clipboard that had been overwritten, and a whole cause was theorised on it | -| 117 | The message pane offers no Select all | workflow | XS | open, found 2026-08-17. NOT caused by item 100: verified by hand against a build with that filter reverted, and the menu holds Copy and the search entries either way | +| 117 | The message pane offers no Select all | workflow | XS | **done** 2026-08-19, unreleased. `addPaneActions()` supplies it. The call site is NOT covered by a test and cannot be: the production menu needs a real context-menu event. Stated in the test rather than faked | | 118 | No way to empty the trash from inside the app | workflow | S | open, 2026-08-17. **Blocked on 103**, which creates the trash in the first place. Deliberately left out of 103's spec at the user's request rather than squeezed in | | 119 | The unsynced-changes count cannot be opened to see what it counts | information | S | open, 2026-08-19, from the notes. One of the four things it sums carries no message ids at all, so a list cannot be complete without a change to how the count is kept | @@ -717,94 +717,6 @@ for the network to satisfy it. **Size: S.** -## 115. A copy from the message pane gives no confirmation - -**Observed (user, 2026-08-17):** Copy link address, Copy image address and Copy -image all work, and none of them says so. The user asked for "a small -'link copied' transient that appears and disappears after a few seconds". - -**Cause:** not a defect, unbuilt. These are Chromium's own menu entries and it -does not report success; nothing in this application is listening to them. - -**Copy image was thought to be broken and is not**; see item 116 in the -closed-items file, which is worth reading for how a stale clipboard reading -produced a confident wrong cause. - -All three work. Copy image was briefly filed as broken (item 116) and is not: -the pixels reach the clipboard correctly, and the reading that said otherwise -was taken off a stale clipboard. So this item covers the confirmation for Copy -link address, Copy image address and Copy image alike. - -**Approach.** `MessageView::statusMessage` already exists and the status bar -already expires its messages (item 33), so this is one connection per action and -no new widget, no new timer. `QWebEnginePage::action()` gives each entry's -QAction; connect `triggered` and emit the appropriate string. - -**Constraints.** - -- The message must name what was copied. "Copied" alone is worse than nothing - when three entries sit next to each other in the same menu. -- Do not build a floating overlay for this. The status bar is where this - application reports transient results, and a second mechanism for the same - job is the kind of thing item 45 recorded when two Sync buttons disagreed. -- Depends on nothing; can be built alongside 114 since both touch the same menu. - -**Size: XS.** - -## 117. The message pane offers no Select all - -**Observed (user, 2026-08-17):** right-clicking a body selection offers Copy and -the search entries, and no Select all. Noticed while hand-testing item 100. - -**NOT caused by item 100, and this was verified rather than argued.** The user -ran a build with `src/messageview.cpp` and `src/messageview.h` reverted to HEAD, -so `removeBrowserActions()` did not exist, and reported the same menu: Copy and -the search entries only. Chromium's standard menu for this pane has never -carried Select all. - -**Three wrong theories preceded that measurement**, which is the part worth -recording, because each was plausible and each cost a round trip: - -1. *The separator sweep removed it.* Disproved with a standalone program - reproducing the sweep against a realistic menu: it drops the leading - separator and keeps every action. -2. *Chromium omits it when there is no selection.* Killed by the user, who had a - selection at the time. -3. *A probe will show what the real menu holds.* `createStandardContextMenu()` - returns NULL outside an actual context-menu event, on the offscreen platform - and on a real display alike, so two probe attempts measured nothing. - -The lesson is the one item 100 had already written down and the agent did not -follow: **a menu built by hand proves nothing about the menu Chromium builds.** -`theBodyMenuDropsTheBrowsersOwnActions` constructs its own QMenu, which is right -for testing the filter and useless for testing what is offered. That test now -says so, and deliberately does NOT assert on SelectAll, since a passing -assertion there would read as a guarantee the code does not make. - -**Approach.** Add it explicitly rather than hoping Chromium supplies it. The -action already exists as `QWebEnginePage::SelectAll` and works; only the menu -entry is missing. - -- `menu->addAction(page->action(QWebEnginePage::SelectAll))` in - `showBodyContextMenu`, placed beside Copy rather than appended after the - search entries. -- Worth considering a `Ctrl+A` binding for the pane at the same time, though - note the pane is not the only focusable widget and the query bar has its own - claim on that key. Check `KeyMap::defaultBindings()` before adding one. - -**Constraints.** - -- **A test for this cannot use a hand-built menu.** That is the trap above. The - honest options are asserting the action is in the menu the production code - returns, which needs a real context-menu event, or leaving it to a hand test - and saying so. Do not write a test that constructs a QMenu and calls it - covered. -- Select all selects the rendered body, not the header label, which is a - separate widget with its own selection. That is probably the desired - behaviour but should be looked at rather than assumed. - -**Size: XS.** - ## 118. No way to empty the trash from inside the app **Observed (user, 2026-08-17):** raised while reviewing item 103's spec, as |