Every view is written with <base target="_blank"> — filesystem.cpp:188,
document.cpp:111, and the same line in the image, text, font, media, pdf and xml
writers. In a browser that opens a new tab. In an embedded web view there is no new tab,
and unless the host implements window opening the tap does nothing at all.
It shows up worst on the archive listing, where the links are the whole point: a zip
renders as a table of its entries and none of them can be opened.
Both readers deal with it themselves. OpenDocument.ios now implements
WKUIDelegate.webView(_:createWebViewWith:…) and loads the request into the web view
that asked, for served URLs only.
Not obviously a bug — a new tab is right in a browser — but every embedder has to
discover and undo it. Some options, if it seems worth it: an HtmlConfig field for the
target, or leaving it off the listing's own entry links, since those point back into the
same service rather than out to the web.
Every view is written with
<base target="_blank">—filesystem.cpp:188,document.cpp:111, and the same line in the image, text, font, media, pdf and xmlwriters. In a browser that opens a new tab. In an embedded web view there is no new tab,
and unless the host implements window opening the tap does nothing at all.
It shows up worst on the archive listing, where the links are the whole point: a zip
renders as a table of its entries and none of them can be opened.
Both readers deal with it themselves. OpenDocument.ios now implements
WKUIDelegate.webView(_:createWebViewWith:…)and loads the request into the web viewthat asked, for served URLs only.
Not obviously a bug — a new tab is right in a browser — but every embedder has to
discover and undo it. Some options, if it seems worth it: an
HtmlConfigfield for thetarget, or leaving it off the listing's own entry links, since those point back into the
same service rather than out to the web.