Open rossjrw opened 2 years ago
Attempted to cache the resize iframe using service workers in #25. Found the following:
There's a workaround where you can request a sentinel file on the current domain that doesn't exist, which is intercepted by the service worker, and have the service worker instead return the file you actually want. E.g. (pseudocode):
// interwiki.js
function resize() {
navigator.serviceWorker.register("/service-worker.js")
resizeIframe.src = "https://interwiki.scpwiki.com/fake-resize-iframe.html"
}
// service-worker.js
self.addEventListener("fetch", request => {
if (
request.url.origin === location.origin &&
request.url.pathname === "/fake-resize-iframe.html"
) {
return request.respondWith(fetch("https://scp-wiki.wikidot.com/resize-iframe.html"))
}
})
That does actually work. However, the iframe is considered to come from the domain that you're spoofing it as (i.e. it thinks it really is https://interwiki.scpwiki.com/fake-resize-iframe.html
), so it's considered a cross-origin resource and can't access the original page, which defeats the point of having the resize iframe be on the same domain as it in the first place.
TLDR this approach is not feasible.
Crom responds really quickly, but the interwiki takes a few seconds to actually appear. The main delay is caused by the loading time of Wikidot's resize script. With a default starting height of 0, which is used to cause the interwiki to be hidden until data and styling has arrived, the interwiki is not initially visible. This was supposed to avoid a bottleneck, but has become a bottleneck itself.
Two possible solutions for this:
visibility: hidden;
, which would preserve height, and debouncing removal of that style.Someone in #javascript recommends Service Workers as a way of manipulating underlying cache fundamentals: https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers
This seems promising: https://developer.mozilla.org/en-US/docs/Web/API/Cache/match