Content preview: web apps have a different sandbox environment than in Kolibri

[dylanmccall]

Observed behavior

As with other content, Kolibri Studio shows a preview of HTML5 apps that have been added to a channel. However, this preview is missing some functionality that is present in Kolibri itself:

• The sandbox does not allow local storage access.
• There is no window.kolibri interface.

Expected behavior

Instead, the preview should work the same as it does inside Kolibri. If this is infeasible, it would be helpful if it was altered in some way to make it clear that the behaviour is different, and to nudge the user toward testing their web app in Kolibri itself instead of in Kolibri Studio.

User-facing consequences

Users who are publishing a web app to a Kolibri channel may be confused when that it behaves incorrectly in Kolibri Studio.

Steps to reproduce the issue

1. In Kolibri Studio, upload a HTML5 zip which uses local storage to persist data.
2. Select the content so it is visible in the preview pane.
3. Note that the local storage features are not functioning.
4. Additionally, inside the iframe, note that window.kolibri is not present.

Usage Details

• OS: Fedora Silverblue 37
• Browser: Firefox 107.0
• URL: https://studio.learningequality.org

[rtibbles]

This is probably best fixed by moving the Studio HTML5 preview to load from the same source as BCK instances do. This would require emulating the external Hashi interface in Studio in order to initialize it with the correct URL, but otherwise would require minimal code changes.

[marcellamaki]

After syncing up with @rtibbles - here are some thoughts on how I'll proceed.

The internal aspects of hashi can be accessed using the GCS bucket, since this contains the latest version (and every version) of hashi.So, since we do not need a zipped backend, and we can access the latest hashi from GCS, the key things to port over into Studio are the files and functions that wrap around the iframe and communicate. We can then send hashi the name of the zip file that has been uploaded, and after checking to see that the unzip has happened, we should be able to render the "inside" part of the iframe the functionality.

Key things to port over

• mainClient.js
• mediator.js

The shims are likely not needed, although it will be important to ensure that the Promises that are related to waiting for responses from the Kolibri API are not held up waiting for a response, and thus preventing the communication between the inside and outside of the iframe.

I will start with a minimal version that is mostly copy and pasted from Kolibri, with slight adjustments to account for:

• the promises and absense of the Kolibri API
• needing a file reference for the hashi HTML file
• making sure the correct version of hashi is used (i.e. rather than always using the latest version in Kolibri develop, which is less stable and could break in production, possibly hard code this from the latest stable release of Kolibri?)

Another potential option for the future would be to publish hashi as an npm package, to avoid having to copy and paste. This could be done in the future or if the "narrow copy and paste" idea turns out to be more complex than originally anticipated, or later on as part of some over hashi cleanup.

Next steps:

• Create a hashi folder under the same folder as the file previewer/content renderer
• Copy the base files over, and go through actually adding the functions into the content renderer

contentcuration/contentcuration/frontend/channelEdit/views/files/hashi/ contentcuration/contentcuration/frontend/channelEdit/views/files/hashi/mediator.js contentcuration/contentcuration/frontend/channelEdit/views/files/hashi/mainClient.js