fix(v2): make hashes recoverable without HTTPS and show all firmware hashes - #4083
Merged
gantoine merged 3 commits intoAug 4, 2026
Merged
Conversation
…hashes The Clipboard API only exists in a secure context, so over plain HTTP the copy button on a hash chip always failed. Because the displayed value is abbreviated in JavaScript, the rest of the hash was never in the DOM either, leaving the full value unreachable on any HTTP install. Clicking a chip now reveals the full value as selectable text whenever a copy cannot land, so Ctrl+C works as a fallback. On HTTP the click no longer attempts the doomed copy, so the misleading error toast is gone. Behaviour over HTTPS is unchanged apart from revealing when a copy throws. The firmware tab only ever showed the MD5, as an unselectable chip with no copy affordance, while the stored CRC and SHA-1 were never displayed. All three now render as copyable chips, matching the ROM files tab. Fixes rommapp#4082 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
Greptile SummaryThe PR makes abbreviated hashes recoverable when clipboard copying is unavailable and expands firmware rows to display SHA-1, MD5, and CRC hashes.
Confidence Score: 5/5The PR appears safe to merge with no concrete blocking or independently actionable non-blocking issues identified. The clipboard composable’s boolean return contract matches the new fallback logic, and the firmware integration follows established HashChip markup and wrapping conventions without introducing conflicting row behavior. Important Files Changed
Reviews (1): Last reviewed commit: "fix(v2): make hashes recoverable without..." | Re-trigger Greptile |
…urface MetadataTab was the only place labelling the row SHA1, while FileRow, FilesSummary and the firmware list all use SHA-1. It was also inconsistent within its own list, sitting directly beside a CHD SHA-1 row. The label is hardcoded rather than translated, so no locale changes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The files list and the firmware list both read SHA-1, CHD SHA-1, MD5, CRC, RA. The metadata tab led with CRC instead, so the same hashes appeared in a different order depending on which tab the user was on. Covers the ordering with a unit test, including the CHD SHA-1 position: the mock library holds no CHD, so that branch cannot be reached in a browser. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gantoine
approved these changes
Aug 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Explain the changes or enhancements you are proposing with this pull request.
Fixes #4082
RomM served over plain HTTP has no way to get a full file hash out of the UI.
Hashes are displayed abbreviated (
012345…234567), and the only way to get thefull value was the copy button, which fails with "Couldn't copy to clipboard.
This requires a secure (HTTPS) connection." The browser's Clipboard API is
gated behind a secure context, so on HTTP it does not exist at all. Because the
abbreviation is generated in JavaScript, the rest of the hash was never in the
page to begin with, so selecting it by hand was not an option either. The data
was genuinely unreachable.
This affects anyone running RomM on a LAN address or a bare hostname without a
reverse proxy terminating TLS. The shipped Docker image has no HTTPS listener,
so this is the default experience for a plain
docker compose upinstall.What changed
Clicking a hash chip now reveals the full value as selectable text whenever a
copy cannot land, so
Ctrl+Cworks as a fallback:the confusing error toast is gone. It reveals the value instead.
the copy itself throws.
is clear without adding any new translated strings.
Separately, the platform Firmware tab only ever displayed the MD5, as a
plain chip with
user-select: noneand no copy button, while CRC and SHA-1 werenever shown at all despite being stored and returned by the API. Firmware hashes
are exactly what you need when verifying a BIOS against a known-good database,
so all three now render as copyable chips, matching the ROM Files tab.
Files changed
frontend/src/v2/components/shared/HashChip.vuerevealedstate, adisplayedcomputed, a state-driven trailing icon, and CSS that re-enables text selection and wrapping when revealed. Used by the ROM Metadata tab, Files tab summary, and per-file rows, so all of them are fixed by this one change.frontend/src/v2/components/Gallery/FirmwareTab.vueHashChipfor SHA-1, MD5 and CRC, each rendered only when present. Drops the now-unused.r-v2-fw__row-hashstyle.frontend/src/v2/components/shared/HashChip.test.tsfrontend/src/v2/components/Gallery/FirmwareTab.test.tsTesting
npm run test— 627 passing across 49 files, no regressions.npm run typecheck— no errors undersrc/.trunk fmt && trunk check— clean.src/v2/; no v1 files are touched.Notes for reviewers
titleattribute changed. It wasLABEL: value (click to copy)and isnow just
LABEL: value. The old suffix would be wrong once the chip isrevealed, and it was hardcoded English in a repo with strict i18n parity, so
dropping it keeps this PR at zero locale changes.
Without that guard, highlighting a revealed hash and releasing the mouse would
fire
clickand collapse the value out from under the selection, defeatingthe whole point. The guard is deliberately scoped to the chip's own subtree so
a selection elsewhere on the page doesn't leave the collapse click dead.
Worth a second opinion: a revealed 40-character SHA-1 wraps to a second line,
which nudges the row height. All the containers involved already use
flex-wrap: wrap, so nothing overflows, but it is a visible layout shift.there is no
aria-expandedor equivalent. Happy to add it if you'd like it inthis PR rather than a follow-up.
FileRowandFilesSummary.AI assistance disclosure
This PR was written with AI assistance (Claude). The root-cause analysis, the
audit of every clipboard call site in v2, the implementation and the tests were
AI-generated, then reviewed and verified by me.
Checklist
Please check all that apply.
Screenshots (if applicable)
New hash reveal on rom file that can be copied when accessing via HTTP (accessing via HTTPS, behavior not modified)

New hash reveal on firmware file that can be copied when when accessing via HTTP (accessing via HTTPS, firmware now gets existing rom behavior)
