Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Study stuck at 'loading experiment' #210

Open
PaulWWarren opened this issue Jul 27, 2023 · 10 comments
Open

Study stuck at 'loading experiment' #210

PaulWWarren opened this issue Jul 27, 2023 · 10 comments

Comments

@PaulWWarren
Copy link

What would you like or expect to see?

I have written an experiment in Builder and exported it under 'offline data collection', then unzipped the file and loaded index.html into a browser (I have tried Chrome, Edge and Firefox with the same problem).

What is currently happening?

The experiment gets stuck at the 'Loading Experiment
The experiment is loading and should start in a few seconds' stage, i.e. it does not move on to the first page proper.

In the console I get the message "core.js:41 The AudioContext was not allowed to start. It must be resumed (or created) after a user gesture on the page. https://goo.gl/7K7WLu", plus lots more.

Please describe the steps needed to reproduce this phenomenon

As described above.

Finally, please tell us which browser you're using (and the version thereof)

Chrome: Version 115.0.5790.102 (Official Build) (64-bit)
Microsoft Edge Version 115.0.1901.183 (Official build) (64-bit)
Firefox 115.0.2 (64-bit)
@mcfarla9
Copy link

Just to be sure, does the study run OK when you do a Preview run from the Builder?

Also that AudioContext always happens, even for perfectly good running lab.js studies, so that message is not diagnostic of your study. It is just an ordinary informational warning, I have not tracked down yet what provokes it in lab.js but again you may safely ignore it.

@PaulWWarren
Copy link
Author

PaulWWarren commented Jul 27, 2023 via email

@PaulWWarren
Copy link
Author

study-export.zip
This is a minimal example. I have uploaded both the exported zip file and the json file describing the test; the latter renamed to .txt because Github won't let me upload a .json.
minimalTest.txt
Having read a bit more about this, I suspect the problem is because the second screen starts with an mp3 file. I think the user needs to do something, e.g. a key press, before the music will play? However, I would have expected this problem to occur when I get to the second screen, but not prevent me even getting to the first screen.

@PaulWWarren
Copy link
Author

I am still puzzled, though, because I have been following the format of a video I found online from Oxford University: https://vimeo.com/558973184 This seems to enable mp3 files without any action from the user.

Finally, for completeness, I have uploaded a .pptx which shows the console messages when the study 'hangs'.
errors280723.pptx

@mcfarla9
Copy link

Thank you for that minimal example, and for the screenshot of your error messages. I can confirm that your example runs for me in Preview (using FF 115.0.2 64-bit), and fails with a CORS error when run from your exported index.html file.

Also, the video that you linked does illustrate the method for adding & using sound in lab.js, but it shows only how to do a Preview run and does not show how to prepare such a study for running locally as an export.

Anyway, it looks like we have run into a fundamental browser security issue. Mischief can occur when a web page from one domain requests resources from outside that domain -- this is called a cross-origin request. Modern browsers impose defenses against that, and more recently consider loading files from the local machine to be the same as a cross-origin request (apparently because attackers will have users first download files to the local machine and then run their malware from there). In fact, here is a link that my error message in FF supplies with a further explanation: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSRequestNotHttp

And indeed, here is the fine print underneath your Timeline entry in the Builder:
"Please note that, for security reasons, audio files must be either embedded in the study, hosted on the same server on which the study is running, or on a server with cross-origin resource sharing enabled. Please also note that Chrome and Safari do not support loading sounds offline; please consider hosting the study on a server instead."

So as a test I uploaded your study-export to our lab.js experiment server, and then it worked fine. You might be able to do much the same yourself by spinning up the server that comes with your OS and running it locally from there, but I have not tried that myself.

That workaround does make development rather more clumsy, but I do not see any way around that. In fact I ran into this very problem recently with some JavaScript that used "import" (actually, while exploring the underlying lab.js source code) and resigned myself to the same conclusion then.

So see if you can run your export from a server, and if that works then I think we have done everything that we can for this issue.

@PaulWWarren
Copy link
Author

Thanks again for the rapid response. I understand what you are saying. I admit, I had read the fine print but not really understood; I had assumed that 'embedded in the study' was what I was doing. I am puzzled why this only applies to audio files. There is no similar problem with a .jpg; I would have thought they could also be dangerous. Anyway, thanks for clarifying this.

@mcfarla9
Copy link

Your observation that the local export handles image files even though it will not handle sound files got me thinking -- lab.js must therefore handle image & sound files through different mechanisms under some circumstances.

So on a hunch I modified your minimal example a bit. To present the sound I use an html.Screen component instead of canvas.Screen, and instead of playing the sound as a Timeline element in the Behavior tab I simply use an audio element in the html content, thus:

<audio autoplay src=${ this.files["53.mp3"] } />

This setup did work for me after exporting for local use. I have attached a .zip file which includes the .json file along with the local export files in case you want to see what I did.

So the Timeline mechanism handles files in some special way that runs afoul of browser same-origin security protections. To understand this further we would need to get someone who understands the lab.js source code.

htmlScreen-sound.zip

@PaulWWarren
Copy link
Author

Thanks again. I have opened your zip file and it works on all three browsers I tried: Chrome, Firefox and MS Edge. I will try your approach on my application. I very much appreciate your help.

@mcfarla9
Copy link

mcfarla9 commented Aug 1, 2023 •
edited

I explored this a little further. Instead of using an html audio element, you could add some "run" script, e.g.,

var myAudio = new Audio( this.files["53.mp3"] );
myAudio.play();

This will work even for a canvas.Screen component. So I took your minimalTest example, removed the audio from the Timeline, and added the script above to play your sound. I have attached a .zip file here that includes both the .json file for the Builder, and my local export.

This still leaves a mystery of why the Timeline mechanism triggers the CORS error and the other mechanisms do not. I also do not know about the timing performance of my workarounds compared to the Timeline mechanism.

-- David McFarlane

AudioRunScript.zip

@PaulWWarren
Copy link
Author

David, Thanks again. That approach could be useful as an alternative to using HTML. I am not particularly concerned about timing performance - at least not in this application.
-- Paul Warren

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@PaulWWarren @mcfarla9