Keep similar puzzles in view when switching between edit and protected mode

[Torgen]

The editable version of the blackboard takes up more space than the protected version, so switching between them can cause the puzzle in view to change. Before entering or exiting, we should check what's roughly in the middle of the viewport, then after re-rendering, scroll the window so that's in the middle again.

[cscott]

Agreed, though it's probably a bit tricky. It might work with scrollspy, though, since scrollspy know what "round" we're looking at, it could probably (more-or-less) easily be made to ensure the same round is visible (as if the round were clicked in the left sidebar) after the switch.

[cscott]

Note that scrollspy's notion of what round we're in is a little bit more subtle than just "what's in the middle of the screen" since it depends on your scroll history. If you scrolled the window down until round X is visible, it assumes that X is the thing you wanted to look at, even if it's still nowhere near the middle of the screen.

...actually i take it back. That's how scrollspy should work, but in practice it seems to highlight the first section that's at-all-visible, whether you're scrolling up or down. IMO it should highlight the first visible section when scrolling up but the last-visible-section when scrolling down, or something like the first "entirely visible section" instead of the first "partially visible section" (when there is an entirely visible section), to better capture both the user's intent while scrolling and also to be more consistent if the currently-highlighted section is clicked. Right now, when a tiny sliver of a section is visible clicking the current-highlighted section will cause a large scroll event; the metric I'm thinking of would be closer to "the highlighted section should be the one which causes the smallest possible scroll event if it were to be clicked", with some bias being given to scroll events which would cause movement in the direction of the most recent user-initiated scroll event (but maybe this bias isn't even needed).

[Torgen]

The real issue here seems to be getting a callback when the rendering has stabilized, unless you're okay with something like setTimeout (-> $.scrollTo whatever), 1000.

[Torgen]

Looks like this is exactly what Tracker.afterFlush is for.