I (Firefox developer working on anything media related) got in contact with the dev on Twitter, and he told me that Web Codecs was missing (and we're shipping this in a month or so, it's been in Nightly for some time), and something to save project file to disk (https://developer.mozilla.org/en-US/docs/Web/API/Window/show...).
So I spoofed the user-agent in a nightly build here on my Linux desktop workstation, then had to alias one method that we should have implemented years ago but only have with a `moz` prefix (`HTMLMediaElement.mozCaptureStream`). This is on us to fix.
Then it looks like a worker script is served with the `Content-Type` `text/html` instead of `application/javascript` or something like that. We also have a pref flip to bypass that check, so I did that, but this is on the dev to fix.
When you do this it works, I've loaded project demos containing videos, audio, various things composited on top, scrubbed the timeline aggressively in a debug build, moved things around in various bits of the interface and also in the rendering frame, etc., things seem to work as they should, perf is as I'd expect it to be (and again, I'm running it in a debug build with optimizations disabled for anything media related, enabled for other parts of the browser).
What's missing is `window.showSaveFilePicker` and file system related stuff. It's possible to use https://developer.mozilla.org/en-US/docs/Web/API/File_System... instead (that we ship, e.g. Photoshop on the Web uses it). We think that it's much less scary than giving access to the file system to a content process of a Web browser. Maybe because videos can sometimes be extremely big files, direct access to the FS could be of use there. Thankfully, we also ship extremely modern video encoders to make them tiny instead, but that's currently a limitation Firefox has, for better or worse.
I would really like to be able to give webpages access to a real local file/folder. It's one of the main barriers to using web apps as production apps and is IMO one of the drivers pushing everything into (generally proprietary, locked in) cloud storage.
Obviously the permissioning model needs to be thought out here. It could perhaps only be available to "PWA"s that have been "installed", only on https sites, and only once explicit permission has been given, etc.
But it's so cumbersome to have upload/download be the only way to sync files into a web app.
Probably the dev needs to use a different method to save (effectively download), much as Adobe Photoshop does when it exports files on Firefox. Not hard to do at all. Likely the same for reading files, if this tool needs that.
OPFS provides high-speed read and write for temporary files and non-exported files; again this is what Photoshop uses. There is a 10GB limit per domain currently. I'm not sure this particular app actually needs that, though
Thanks for taking the time to investigate what's currently the gap with FF. As a long-time Firefox user, I'm hoping you can guide this dev regarding ways to get things working from his end while also using this app's needs to inform FF improvements from your end.
> Why no Firefox support
Firefox is my daily web browser. As a web developper, I always make sure my work is comptatible with all major browsers. But you can guess a web based video editor is a complex task to achieve, and Pikimov uses several key features that only exist in Chrome, Edge, and maybe Opera, and maybe, maybe, Brave. That's why Pikimov cannot currently work on Firefox (as of today: v127), there's nothing I can do to fix this, it is just not possible. For the curious ones, here are some of the web API Pikimov requires, but are missing from Firefox: - audio data - window showsavefilepicker - videoencoder Note: There is no Safari support due to similar obstacles.
As I mentioned in another comment, in short, WebCodecs and File System Access API I believe. Both pretty essential for an app designed for editing large video files from disk.
IME the features are often mostly there same but there are small implementation differences/bugs at least in the newer APIs. Firefox is no more buggy (often less), but it's easier to code for one set of bugs. Safari is by far the worst.
I use Firefox for all my browsing, but do web app development with and for Chromium. I'd gladly do it for Firefox, but people, especially users, suck and sometimes one has to accept this.
Glad to see no time is wasted for Safari/iOS support. It's a huge waste of time and people using Apple devices are to blame.
It took Firefox 17 years of back and forth with developers to add parity with an Internet Explorer feature that Chrome supported since version 1. This late in the game IE is already dead for good.
Not everybody has infinite time or infinite money to support Firefox, as an aside, you knew what you signed up for when you made Firefox your main browser.
So please, change the "clarify why you don't support Firefox" tone with "I want to make the site work with Firefox, how can I help you?". And good luck making the Firefox team change their mind when they decide not to support X feature, because it is also their right to do not implement the whole spectrum of features that Chrome supports.
Probably the same features that computers have had since the 1960s, but nobody writes native applications anymore. Guess I'll have to pass on this one. I wish Chrome weren't the only operating system people chose to write software for.
