Unable to play mp4 files stored in local file system using<video> tag

[sierrodc]

• I have read the contribution documentation for this project.
• I agree to follow the code of conduct that this project follows, as appropriate.
• I have searched the issue tracker for an issue that matches the one I want to file, without success.

I'm trying to create a video player using electron.
Video files (mp4) are stored locally in the filesystem.
It is working correctly if I run

• electron-forge start

But the video is not loaded if I run the generated executable created by

• electron-forge package --platform=win32 --arch=x64

I'm using the latest version of packages (electron-forge 2.8.2 that still uses electron 1.4.15)

How to reproduce:

• electron-forge init myprj
• cd myprj
• download mp4
• add follogin tag in index.html:
  
• electron-forge start <-- this works fine
• electron-forge package --platform=win32 --arch=x64
• cd out/myprj...
• run myprj.exe <-- this doesnt' work

[MarshallOfSound]

@sierrodc Can you provide the code that you are using to load the video files. I believe electron-compile effectively sandboxes your app so that files that aren't precompiled can't be loaded at runtime. Not sure if this is actually the case without seeing your code though, could be a generic path change issue 👍

/cc @paulcbetts ^^ thoughts

[sierrodc]

Hi,

I've uploaded sample source code here:
https://github.com/sierrodc/videoplayer

You need to change mp4 file url in the index.html page.

Thanks.

[anaisbetts]

I think @MarshallOfSound has the right idea, we should probably provide an opt-in escape hatch for this in electron-compile, something like a insecurefile:// scheme that will just blindly return a file job

[sierrodc]

Got it.

Do you know if there's a workaround for this?
If I put the video during compilation time it works fine but this is not what I need.

I've also tried (after adding the video during compilation time) to overwrite using fs the video in output but in this case always the "compiled" video is used.

Is this a problem related to electron-forge or electron? Is there a workaround? what about electron-packager/electron-builder? I really need this functionality. Do you have any suggestions?

[MarshallOfSound]

@sierrodc The easiest workaround is to register a custom protocol yourself and bypass electron-compile entirely. In the mean time I'll look into adding an option to the protocol hook in -compile to selectively bypass the compiler for certain URI's.

[MarshallOfSound]

@sierrodc See electron-userland/electron-compile#199

[anaisbetts]

I'm gonna have a look at this tomorrow, I want to make this a bit harder for people because I don't want there to be a super easy "Copy paste this to disable security" line

[sierrodc]

Hi, a feedback:

1. Thank you very much Marshall, your solution works perfectly. I've tested it both in windows and on a raspberry pi 3.
2. about your "suggestion" to register this function:
   addBypassChecker((filePath) => {
   return filePath.indexOf(app.getAppPath()) === -1;
   });
   If I do it, an electron-forge application created using angular-template doesn't work anymore (error similar to "invalid token import" in bootstrap.ts).
   But if I add
   addBypassChecker((filePath) => {
   return filePath.indexOf(app.getAppPath()) === -1 && /.mp4/.test(filePath);
   });
   everythings works fine for me.

Thank you again.
@paulcbetts what kind of "security" issue are you afraid of? "fs" is anyway available to read/write the filesystem.

[jamesmoore]

@sierrodc
The errors are caused by two things:

1. In windows OS the apppath has \ as path separator, but the file will have /. Therefore you would need to use app.getAppPath().split("\\").join("/")
2. in debug mode the app path is like

.....\node_modules\electron-prebuilt-compile\node_modules\electron\dist\resources\default_app.asar

but the filepath is any file served from the application (including the .ts), or external to it.
Both these means that the indexOf will return -1, even for .ts files that it should be compiling, hence the error.

It seems hardcoding the extension is the best way for now, but interested if others have ideas.