mirror of
https://github.com/alexbelgium/hassio-addons.git
synced 2026-09-03 16:33:32 +02:00
59690b157d
* fix(filebrowser_quantum): keep the no-preview Download and Open file links inside the ingress panel 1.5.3.2 fixed the download anchor api/resources.js builds and clicks itself, but the 'no preview available' screen -- what a .zip or .bin gets -- offers its own Download and 'Open file' buttons as target="_blank" links, and so does the share list in settings. The companion app has no navigationAction policy delegate, so every new-window request reaches createWebViewWith and is handed to an external browser, which carries no ingress session cookie: 401. Replaces the wrapper around HTMLAnchorElement.prototype.click with a single capturing click listener. It reaches the hidden anchor exactly as before -- a programmatic .click() dispatches through the document like a real one -- and also the two the user clicks, which the wrapper never saw. Downloads gain the attribute everywhere; dropping target="_blank" is limited to the companion app, identified by the Mobile/HomeAssistant marker it appends to the user agent, because in a real browser a new tab is the better behaviour. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(filebrowser_quantum): leave modified clicks alone, and correct the comments Review of #3033 found that the listener ran for every click, so a cmd/ctrl/shift-click on the visible Download link -- an explicit request for a separate context -- was turned into a download instead. It now only touches unmodified primary clicks, which is also what a programmatic .click() reports (button 0, no modifiers), so the hidden anchor is unaffected. Also corrects three overclaims: the listener reaches connected anchors only (both shipped download paths append theirs first); absolute sidebar links go through window.open rather than an anchor and are not covered; and links inside the pdf, srcdoc-preview and OnlyOffice iframes are a separate document this listener never sees. Records that an error response is now saved as a file. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(filebrowser_quantum): say why the download branch also drops target Review of #3033 read the unconditional target removal as contradicting the comment above it. The removal is deliberate: with the download attribute set, a same-origin link downloads and never opens a tab, so it changes nothing in a browser (measured), but it stops the companion app from taking its new-window path before it considers the download -- an ordering not testable from outside iOS. The comment now says so. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>