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.
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
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.
> 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.
- https://github.com/mozilla/gecko-dev/blob/af09c55c0e6253ba8f...
- https://github.com/mozilla/gecko-dev/blob/af09c55c0e6253ba8f...
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 is the right of developers to say "I don't want to support your browser" and you should respect that decision even if you disagree with it.
As a reality check, see this ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=390936
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.
I think they genuinely were interested to learn more about the deficiencies of Firefox.
I did - a better browser than Internet Explorer. Granted, that was 20 years ago.