difficulty_ladder's glass HUD paints over section_map's bar

Summary

plugins/difficulty_ladder/screen.js and plugins/section_map/ (feedBack-plugin-sectionmap) both independently render a difficulty/glass visualization from the same highway.getPhrases()/hasPhraseData()/getMastery() data (confirmed intentional, no shared API — see difficulty_ladder/INTEGRATION.md), but nobody coordinated their screen real estate:

section_map pins a ~20px bar to the very top of #player (top:0, full width, z-index:5) and draws small glass icons inline inside its own section blocks.
difficulty_ladder's ensureHudCanvas() (screen.js) creates a separate floating canvas (#dynamic-difficulty-hud) at top:8px; left:50%; transform:translateX(-50%); z-index:15, up to GLASS_MAX_H + 12 = 56px tall (y range ~8–64px).

Since difficulty_ladder's HUD has a higher z-index (15 > 5) and its vertical band (8–64px) overlaps section_map's bar (0–20px) at the horizontal center of the screen, whenever both plugins are active and the current song has phrase data, difficulty_ladder's translucent glass icons paint directly over the middle of section_map's bar — visually breaking/hiding the sections there.

Fix

Mirror the existing #section-map ~ #player-hud core CSS pattern (static/style.css) that already solves this exact conflict for the player HUD: offset difficulty_ladder's canvas below section_map's bar when it's present.

Patch applied locally in ensureHudCanvas():

```js
function _hudTopOffset() {
return document.getElementById('section-map') ? 28 : 8;
}
// ...
_hudCanvas.style.cssText =
'position:absolute;left:50%;transform:translateX(-50%);' +
'pointer-events:none;z-index:15;top:' + _hudTopOffset() + 'px;';
```

Checked once per canvas (re)creation rather than every rAF tick, consistent with this plugin's own per-frame-DOM-query rule in CLAUDE.md.

Note

This was found while investigating a separate report of section_map's bar not rendering at all (barExists: false in the reporter's DOM, independent of this overlap) — that root cause is still open and being tracked separately. This issue is scoped only to the z-index/positioning conflict between the two plugins' independent glass overlays when section_map's bar IS present.

@pullfrog please take this (Effort: Low). Note that the fix described lives in the difficulty-ladder plugin (ensureHudCanvas() in get-flashbacks/feedback-plugin-difficulty-ladder), not in core, so open the PR there. First check whether the overlap still reproduces on current main: Section Map issue feedBack-plugin-sectionmap#14 and difficulty-ladder #131 plan to replace the glass HUD with a tier rail, which may make this moot. If it does still reproduce, apply the minimal offset described in the issue (checked once per canvas creation, not per frame, per that repo's CLAUDE.md), bump the version, and open a PR against main; don't merge it. If it no longer applies, say so here instead of patching.

Generated by Claude Code

No patch needed — the overlap no longer reproduces on difficulty_ladder's current main. (No PR opened; nothing to bump.)

Why it's moot

drawHud() in get-flashbacks/feedback-plugin-difficulty-ladder@main (screen.js:2567) already bails out before ensureHudCanvas() is ever reached when Section Map is present:

var sectionMapOwnsGlasses = !!window.__slopsmithSectionMapHooksInstalled;   // :2578
if (!settings.showGlasses || sectionMapOwnsGlasses || (ss && …isActive())) {
    if (_hudCanvas) _hudCanvas.style.display = 'none';
    return;                                                                // :2583
}
var canvas = ensureHudCanvas();                                            // :2589 — never runs

So when both plugins are installed, Difficulty Ladder's HUD canvas is never created and never shown; there is no second surface to overlap #section-map's bar, and the z-index: 15 vs 5 / 8–64px-vs-0–20px geometry in this issue simply can't occur. The marker is set at script-eval time by Section Map's own screen.js (__slopsmithSectionMapHooksInstalled, present in both the fork and got-feedback/feedBack-plugin-sectionmap), and core never scrubs it. Load order doesn't matter either: Difficulty Ladder sorts earlier alphabetically, but the gate is re-evaluated every frame, so it self-corrects on the next tick regardless.

Timeline — this was real, and got fixed after the report

The mutual exclusion landed in PR #61 (merge commit 400aea325, 2026-08-17), shipped as 0.8.3, whose CHANGELOG entry reads: "Its standalone glasses HUD also yields to Section Map's section-bar glasses, preventing the duplicate display." This issue was filed 2026-08-06, eleven days earlier — the reporter was looking at pre-#61 code. I bisected screen.js across the history to confirm: __slopsmithSectionMapHooksInstalled is absent at 400aea325^ and present at 400aea325, and absent in every earlier revision. Nineteen commits have touched screen.js since, none of which removed the gate.

Current main is b07039b / plugin.json 0.23.9.

The proposed patch would be dead code

ensureHudCanvas() still hardcodes top:8px (:2556), but that branch is now unreachable whenever #section-map exists — so a _hudTopOffset() returning 28 would never fire. Adding it would add a function and a conditional guarding a state the plugin has already made unreachable. The CLAUDE.md per-frame-DOM rule would be respected either way; there's simply nothing left to protect.

On the tier rail

Not the reason, but worth noting for tracking: feedback-plugin-difficulty-ladder#131 and feedBack-plugin-sectionmap#14 are both still open, neither has an open PR in either repo, and #131 explicitly lists "Installing Section Map silently suppresses and relocates the standalone HUD through window.__slopsmithSectionMapHooksInstalled" as a flaw to clean up. So the glasses → tier-rail migration hasn't started; this issue is closed out by the existing suppression rather than by that work.

One caveat: I verified this by reading the plugin sources on main, not by running the app — the sandbox has no Section Map + Difficulty Ladder install to drive a browser against. The suppression is unconditional and load-order-independent as far as I can tell, but if someone still sees stacked glasses in a live install, that's worth a fresh report rather than reopening this one.

(This issue is already labelled invalid, so no further triage action from me — closing it is a maintainer call.)

Task list (4/5 completed)

Read event context (issue difficulty_ladder's glass HUD paints over section_map's bar #48 comment) and learnings relevant to plugins
Determine whether the Section Map / glass HUD overlap still reproduces on difficulty-ladder main
Check sectionmap#14 and difficulty-ladder#131 status (tier rail replacement)
~~If still reproducing: apply minimal offset in ensureHudCanvas(), bump version, open PR~~
Report outcome (no-op: overlap already prevented on main)

^{｜ View workflow run ｜ via Pullfrog ｜ Using big-pickle (free) ｜ 𝕏}

Navigation Menu

Repository navigation

difficulty_ladder's glass HUD paints over section_map's bar #48

Summary

Fix

Note

Why it's moot

Timeline — this was real, and got fixed after the report

The proposed patch would be dead code

On the tier rail

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

difficulty_ladder's glass HUD paints over section_map's bar #48

Description

Summary

Fix

Note

Activity

cchacs commented on Oct 1, 2026

pullfrog commented on Oct 1, 2026

Why it's moot

Timeline — this was real, and got fixed after the report

The proposed patch would be dead code

On the tier rail

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions