Interwiki takes a few seconds to appear

[rossjrw]

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:

• Somehow force the browser to cache the resize script, and use that cache whenever possible.
• Start at a non-zero height and only use the resize script to become smaller.
  • The contents of the iframe will need to be inititally hidden in this case, because currently the contents are considered implicitly hidden by assuming the starting height is 0. Setting the starting height to non-zero without any additional changes will cause the iframe to display with janky styling for a sec.
  • This could be achieved by initially giving the interwiki contents 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

[rossjrw]

Attempted to cache the resize iframe using service workers in #25. Found the following:

• Service workers can cache any request, and in theory caching the resize iframe source would work.
• An iframe's requests take place in a separate browsing context, equivalent to a different browser tab. Therefore a service worker registered in a given window cannot intercept requests from an iframe in that window.
• The initial request for an iframe's source also takes place in that isolated browsing context. Therefore a service worker in the interwiki cannot intercept the request for the resize iframe's src.

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.