Skip to content

Fix: Draw the top bar again wherever it was drawn away from its clicks - #189

Merged
b-re-w merged 2 commits into
developfrom
feat/bar-place
Nov 9, 2026
Merged

b-re-w merged 2 commits into
developfrom
feat/bar-place

Conversation

@b-re-w

@b-re-w b-re-w commented Nov 9, 2026

Copy link
Copy Markdown
Member

After #184, the release bar-folded scene passes on Chrome and Edge (.scratch\bar-rows-after). It still fails on Whale 5.39: after each fold or show, the bar stays painted at its previous place, for example "step 2 shown by the button: Back painted at 59-94 hits 2". Whale moves the panel without the frame layout notice that panel_moved hangs on.

  • toggle_appbar asks for a bar repaint (frame::request_bar_paint, the posted Rivet.BarMoved).
  • address_bar::part_at, which the window's hit test uses, asks for a repaint when the bar's place for clicks differs from where view last drew it. The pointer's own hit tests come before any click, so the bar is drawn where it takes clicks first.

Test: fr12_a_bar_drawn_where_it_no_longer_takes_clicks_is_drawn_again.

🤖 Generated with Claude Code

b-re-w and others added 2 commits November 10, 2026 05:15
On Whale the browser moves the panel without the layout notice the bar repaints on, so after a
fold the bar stayed drawn at its old place. Folding now asks for a repaint, and a hit test that
finds the bar's place differs from where it was drawn asks for one before the click arrives.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@b-re-w
b-re-w merged commit ed28982 into develop Nov 9, 2026
3 checks passed
@b-re-w
b-re-w deleted the feat/bar-place branch November 9, 2026 20:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant