3 ms·

Hi! Engineer who actually works on Clipchamp. Sorry you ran into that issue. Firefox support is in the works - we plan to support the same set of browsers as t

Hi! Engineer who actually works on Clipchamp. Sorry you ran into that issue. Firefox support is in the works - we plan to support the same set of browsers as the other Office features, as described here: https://support.microsoft.com/en-us/office/which-browsers-work-with-office-for-the-web-and-office-add-ins-ad1303e0-a318-47aa-b409-d3a5eb44e452 https://support.microsoft.com/en-us/office/which-browsers-wo... If this tech looks interesting, come join us! We have a bunch of open engineering positions in Brisbane that are 100% WFH from Australia: https://careers.microsoft.com/us/en/search-results?keywords=Clipchamp https://careers.microsoft.com/us/en/search-results?keywords=...

capableweb 4y ago
What, exactly, is making the website work fine on Chrome/Edge but not on Firefox? Are you using some bleeding-edge API that isn't available in Firefox yet?
- xyzzy_plugh 4y ago
  In my experience it's simply developer resources. In my entire career, I've never seen a complex web app "just work" across multiple browsers without some, if not a lot of, effort. Testing on all browsers all the time is a significant cost to velocity. It almost always makes more sense to build for a single browser first, then figure out where the comparability issues are once you have an actual product.
  - capableweb 4y ago
    > It almost always makes more sense to build for a single browser first, then figure out where the comparability issues are once you have an actual product. I agree, and most places I've worked with has been the same. But I think only once, after following that process, have we ended up in "Damn, this works 100% in Chrome but is completely broken in Firefox". Sometimes something works faster/slower in Chrome/Firefox, but without requiring something like the Web MIDI API, most things just works the same across browsers, minus some minor things regarding CSS that has to be taken into consideration. I guess what I'm looking for with my previous comment, is not so much of a general/philosophical answer of "Why you block Firefox but not Chrome?" but rather a specific answer to "What ended up being broken in Firefox but working in Chrome?" Mostly helpful for my own curiosity, but in the strange case of finding things that works in Chrome but not Firefox, leaving a report at https://webcompat.com/ https://webcompat.com/ can be very helpful for the general health of the web as well.
    - xyzzy_plugh 4y ago
      In my experience it's subtle bugs that don't appear on one platform but do in the other. webcompat is great for true deviations from the spec but there are plenty of cases where things work for no good reason and it's a chore to figure out why. I'm also a bit curious why blocking Firefox is preferred versus stating which browsers are supported.
- pragmatic 4y ago
  https://caniuse.com/?search=worker%20module https://caniuse.com/?search=worker%20module This is something I just personally bumped into in switching from webpack to vite (svelte app). Not often that FF is the problem. Usually it's Safari but that is becoming less common. I think I can work attend it, we'll see next week.
aliswe 4y ago
Hi, am I being obstinate for thinking "Sorry you ran into that issue" is a bit strangely worded?
- lupire 4y ago
  It's just corpspeak.

capableweb 4y ago

What, exactly, is making the website work fine on Chrome/Edge but not on Firefox? Are you using some bleeding-edge API that isn't available in Firefox yet?

xyzzy_plugh 4y ago
In my experience it's simply developer resources. In my entire career, I've never seen a complex web app "just work" across multiple browsers without some, if not a lot of, effort. Testing on all browsers all the time is a significant cost to velocity. It almost always makes more sense to build for a single browser first, then figure out where the comparability issues are once you have an actual product.
- capableweb 4y ago
  > It almost always makes more sense to build for a single browser first, then figure out where the comparability issues are once you have an actual product. I agree, and most places I've worked with has been the same. But I think only once, after following that process, have we ended up in "Damn, this works 100% in Chrome but is completely broken in Firefox". Sometimes something works faster/slower in Chrome/Firefox, but without requiring something like the Web MIDI API, most things just works the same across browsers, minus some minor things regarding CSS that has to be taken into consideration. I guess what I'm looking for with my previous comment, is not so much of a general/philosophical answer of "Why you block Firefox but not Chrome?" but rather a specific answer to "What ended up being broken in Firefox but working in Chrome?" Mostly helpful for my own curiosity, but in the strange case of finding things that works in Chrome but not Firefox, leaving a report at https://webcompat.com/ https://webcompat.com/ can be very helpful for the general health of the web as well.
  - xyzzy_plugh 4y ago
    In my experience it's subtle bugs that don't appear on one platform but do in the other. webcompat is great for true deviations from the spec but there are plenty of cases where things work for no good reason and it's a chore to figure out why. I'm also a bit curious why blocking Firefox is preferred versus stating which browsers are supported.
pragmatic 4y ago
https://caniuse.com/?search=worker%20module https://caniuse.com/?search=worker%20module This is something I just personally bumped into in switching from webpack to vite (svelte app). Not often that FF is the problem. Usually it's Safari but that is becoming less common. I think I can work attend it, we'll see next week.

aliswe 4y ago

Hi, am I being obstinate for thinking "Sorry you ran into that issue" is a bit strangely worded?

lupire 4y ago
It's just corpspeak.