diff options
author | Kartik K. Agaram <vc@akkartik.com> | 2016-02-01 13:29:46 -0800 |
---|---|---|
committer | Kartik K. Agaram <vc@akkartik.com> | 2016-02-01 13:37:12 -0800 |
commit | 07a6418389a6c36c0fe9cded6e585fb013ec90e1 (patch) | |
tree | 7c6cd399cc2b741b0befc47023cf264cb4796adb /html/edit/010-warnings.mu.html | |
parent | 34a2336e41daa20f02f20ae995d6c17ea0b3127f (diff) | |
download | mu-07a6418389a6c36c0fe9cded6e585fb013ec90e1.tar.gz |
2623 - bugfix: editing sandboxes
If you restore 2 sandboxes, the first render was setting response-starting-row-on-screen on both, without ever rendering a response. If the lower sandbox contained a print and rendered the screen instead of the response, the original response-starting-row-on-screen was never reset. If the process of running the sandboxes caused the lower sandbox's title bar to move below the now-stale response-starting-row-on-screen[1], editing the lower sandbox no longer works. [1] (Either because the upper sandbox prints to screen as well (causing the first F4 to move the lower sandbox down by several lines), or because a fresh sandbox is created with several lines before the first F4 is hit.) Current solution: never set response-starting-row-on-screen during reload (or otherwise when there's no response). This is hard to test right now because 'restore' is not a tested interface, and I can't come up with another situation where the response-starting-row-on-screen goes stale. So I'm now trying to keep all changes to response-starting-row-on-screen close together. Another idea is to add a check that the click row lies below the response-starting row *and* above the start of the next sandbox. (But what if there's no next sandbox?) (This bug is really a regression, introduced last Sep in 2163.)
Diffstat (limited to 'html/edit/010-warnings.mu.html')
0 files changed, 0 insertions, 0 deletions