A generated report points at its neighbours. acties.html links to dashboard.html#AST-DHR-AIT-0009, and clicking that in the HTML preview does nothing at all.
Why it does nothing
The preview runs in a srcdoc iframe with sandbox="allow-scripts" — no origin of its own, so it cannot navigate: a relative URL has nothing to resolve against. The bridge catches the click and then drops it:
} else {
ev.preventDefault(); // relatief e.d.: niet laten navigeren binnen de sandbox
}The parent, however, can read the target file and render it again. That is the route this proposes.
Opening that up should not turn the bridge into a pass-through: the page is generated, untrusted HTML, and it can post a message without a click at all. So the parent should not take the page's word for where a link points.
Two things measured along the way
Running the real bridge inside a sandboxed iframe in Chromium turned up two things that are not visible from reading the code:
scrollIntoView({behavior: 'smooth'}) does nothing in this sandbox. scrollY stays 0, with no error. scrollTo and scrollIntoView() without smooth both work (measured: 500 and 1504 on the same document). The bridge has used smooth since it was written, which means in-document anchors in the preview have never actually jumped — including the #heading links the README credits the Markdown renderer with ("working in-document anchors").
A jump on DOMContentLoaded is undone. It scrolls, and then the browser resets the scroll position once the document finishes loading. Anything that jumps to an incoming fragment has to try again after load.
Proposed change
- The bridge sends a relative link to the parent as a request, the same way it already relays
http(s)/mailto. Other schemes (javascript:, data:) keep doing nothing.
preview_link_target in Rust decides whether that link may be followed: relative only (no scheme, no drive letter, not root-anchored), .. collapsed lexically rather than with canonicalize — that one follows symlinks and could step outside the boundary — the result checked component-wise against the session folder (a string compare would confuse C:\work with C:\workspace), and limited to html/htm/md, the same set scan_html lists. Anything else resolves to nothing, exactly as today.- A page opened outside the session folder (a path clicked in the terminal) falls back to its own folder as the boundary, so its neighbours still work.
scrollIntoView without smooth, and the incoming fragment retried after load.
The file picker above the preview follows the navigation, so it doubles as the way back.
A generated report points at its neighbours.
acties.htmllinks todashboard.html#AST-DHR-AIT-0009, and clicking that in the HTML preview does nothing at all.Why it does nothing
The preview runs in a
srcdociframe withsandbox="allow-scripts"— no origin of its own, so it cannot navigate: a relative URL has nothing to resolve against. The bridge catches the click and then drops it:The parent, however, can read the target file and render it again. That is the route this proposes.
Opening that up should not turn the bridge into a pass-through: the page is generated, untrusted HTML, and it can post a message without a click at all. So the parent should not take the page's word for where a link points.
Two things measured along the way
Running the real bridge inside a sandboxed iframe in Chromium turned up two things that are not visible from reading the code:
scrollIntoView({behavior: 'smooth'})does nothing in this sandbox.scrollYstays 0, with no error.scrollToandscrollIntoView()withoutsmoothboth work (measured: 500 and 1504 on the same document). The bridge has usedsmoothsince it was written, which means in-document anchors in the preview have never actually jumped — including the#headinglinks the README credits the Markdown renderer with ("working in-document anchors").A jump on
DOMContentLoadedis undone. It scrolls, and then the browser resets the scroll position once the document finishes loading. Anything that jumps to an incoming fragment has to try again afterload.Proposed change
http(s)/mailto. Other schemes (javascript:,data:) keep doing nothing.preview_link_targetin Rust decides whether that link may be followed: relative only (no scheme, no drive letter, not root-anchored),..collapsed lexically rather than withcanonicalize— that one follows symlinks and could step outside the boundary — the result checked component-wise against the session folder (a string compare would confuseC:\workwithC:\workspace), and limited tohtml/htm/md, the same setscan_htmllists. Anything else resolves to nothing, exactly as today.scrollIntoViewwithoutsmooth, and the incoming fragment retried afterload.The file picker above the preview follows the navigation, so it doubles as the way back.