Found on hardware during the rc30 verification round (7.14.2, 23af3085c).
Summary
The Cut Off pre-screen tells the user:
This text is too long for the screen. Only part of it is shown.
Hold to view it anyway.
Holding does not reveal anything. lib/board/confirm_sm.c:441 re-draws the same
truncated body:
return confirm_screen(request_title, request_body, layout_notification_func,
constant_power, iconNum, immediate);request_body is unchanged, and the generic confirm() path has no pager. The
byte-exact pager with n/m counters (confirm_bytes(), app_confirm.c) exists
only for the three SignMessage handlers. So the hidden remainder stays hidden and
the second hold shows the user nothing new.
Why it matters
This is a consent screen. It states that the device is about to disclose the part
it could not fit, and then does not. A user who reads it carefully is misled about
what they are approving — worse than not warning at all, because the warning
implies disclosure happened.
Confirmed on hardware at 118, 119 and 255 characters: the post-warning screen is
byte-identical to the pre-warning screen.
Two ways to fix
A. Correct the copy (cheap, honest). Say the remainder cannot be shown:
Only part of this text is shown and the rest cannot be displayed.
Hold to continue anyway.
Near-zero ROM. Does not improve disclosure, but stops the device claiming
something untrue.
B. Paginate the generic confirm() path (correct, costs ROM). Give
confirm_helper() the same treatment confirm_bytes() already gives SignMessage:
pre-count pages, add n/m to the title, one hold per page. Actually discloses the
body. More code, more ROM, and more holds on every over-long confirmation.
Note that B interacts with #484 — more consecutive screens means more places a
release bounce can be miscounted as consent. #484 should land first either way.
Boundary, for reference
The warning fires at 118 characters for a plain body, verified on hardware.
That is #481's fix working: a clipped final glyph no longer reports as fitting.
Full write-up: docs/release/rc30-evidence/T5-cutoff-findings.md.
Found on hardware during the rc30 verification round (7.14.2,
23af3085c).Summary
The Cut Off pre-screen tells the user:
Holding does not reveal anything.
lib/board/confirm_sm.c:441re-draws the sametruncated body:
request_bodyis unchanged, and the genericconfirm()path has no pager. Thebyte-exact pager with
n/mcounters (confirm_bytes(),app_confirm.c) existsonly for the three SignMessage handlers. So the hidden remainder stays hidden and
the second hold shows the user nothing new.
Why it matters
This is a consent screen. It states that the device is about to disclose the part
it could not fit, and then does not. A user who reads it carefully is misled about
what they are approving — worse than not warning at all, because the warning
implies disclosure happened.
Confirmed on hardware at 118, 119 and 255 characters: the post-warning screen is
byte-identical to the pre-warning screen.
Two ways to fix
A. Correct the copy (cheap, honest). Say the remainder cannot be shown:
Near-zero ROM. Does not improve disclosure, but stops the device claiming
something untrue.
B. Paginate the generic
confirm()path (correct, costs ROM). Giveconfirm_helper()the same treatmentconfirm_bytes()already gives SignMessage:pre-count pages, add
n/mto the title, one hold per page. Actually discloses thebody. More code, more ROM, and more holds on every over-long confirmation.
Note that B interacts with #484 — more consecutive screens means more places a
release bounce can be miscounted as consent. #484 should land first either way.
Boundary, for reference
The warning fires at 118 characters for a plain body, verified on hardware.
That is #481's fix working: a clipped final glyph no longer reports as fitting.
Full write-up:
docs/release/rc30-evidence/T5-cutoff-findings.md.