"Quest for the Teacup of Minor Sentimental Value" not playable in Unbox

[dfabulich]

https://if-foundation.slack.com/archives/C61AKJ7CY/p1725551258906649

The browser version of Damon L. Wakes' RPGMaker entry (Teacup) doesn't appear to be playable through Unbox, for some reason :confused: ("SecurityError / The operation is insecure." Firefox 115esr.) (It works on the IFComp site. No updates declared. It doesn't work loaded into browser from local files, but I think that's not unusual these days.)

The full game title is, "Quest for the Teacup of Minor Sentimental Value"

/if-archive/games/competition2024/Games/QftToMSV-Windows-and-Linux.zip

Chrome has a more detailed error message.

Failed to execute ‘getImageData’ on ‘CanvasRenderingContext2D’: The canvas has been tainted by cross-origin data.

[dfabulich]

It's a little hard to be sure, but I think the issue may have to do with the 301 redirects from https://23nwbwjk2e.unbox.ifarchive.org/23nwbwjk2e/ to //unbox.ifarchive.org/23nwbwjk2e/

I note that the 301 redirects themselves don't have any CORS headers, but I doubt that adding CORS headers there will be sufficient.

[dfabulich]

I see. Even though the CORS headers are perfectly cromulent, canvas doesn't like it when its image data is on a remote origin.

It would be possible in principle to update the canvas JS code to make this work, by setting a crossOrigin parameter on image data, but that would require updates to the game itself. (I think JS code was authored/generated by RPGMaker, so we'd have to get them to fix their bug, publish a new version, and then the author would have to upgrade and re-generate the HTML export using the fixed version.)

If I were the RPGMaker team, I'd say that adding support for crossOrigin images is actually a feature request, not a bug, and that ensuring that it didn't break in the future would require additional testing and support. I'd probably reject the feature request if I were them!

[dfabulich]

But, then again …

The JS code is unminified. I was able to replace line 1679 of rpg_core.js:

@@ -1675,7 +1675,7 @@ Bitmap.prototype._requestImage = function(url){
         this._loader = ResourceHandler.createLoader(url, this._requestImage.bind(this, url), this._onError.bind(this));
     }

-    this._image = new Image();
+    this._image = new Image(); this._image.crossOrigin = "anonymous";
     this._url = url;
     this._loadingState = 'requesting';

… and then it started working.

It's not the least bit clear what we should do with this finding. We could do something like this:

1. Change the file ourselves by hand. (With the author's permission?)
2. Ask the author to change this file, and to remember to continue patching the file in the future.
3. Ask RPGMaker(?) to add this to rpg_core.js, and to release a new version, and ask the author to use the new version in the future.
4. Or, apply my PR #63, and manually enable Cloudflare caching for 23nwbwjk2e.unbox.ifarchive.org

[dfabulich]

On IFTF Slack it seems like we kinda settled on PR #63, instead of PR #62 (or just asking the author to fix it).

https://if-foundation.slack.com/archives/C61AKJ7CY/p1725576050826199

My feeling is that #2 (PR #63) is pretty close to ideal. I think to make it truly ideal, we’d add a metadata field to Master-Index.xml to track it, but, considering that this is the first instance of this bug we’ve encountered so far, and we might not encounter another one for years, it feels premature to build out infrastructure in the admin tool to track this.

I say: hard code it until we have at least three ZIPs containing HTML whose resources must be loaded from the same domain, then build a fancier tool for tracking it.