Hacker News Reader

Comment by kuratkull | Hacker News Reader

Firefox users are asked to please stay away:

It looks like your browser is not supported To use Clipchamp, make sure you're using the latest version of Google Chrome, or the latest Microsoft Edge

View on HN

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-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=...

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?

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.

> 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/ can be very helpful for the general health of the web as well.

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.

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.

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

It's just corpspeak.

Feels like 2000s again, we are supposed to switch browser for each site again.

It helps when Mozilla has a backbone and shows up to the standards meetings.

Using Firefox with the user agent changed to chrome seems to get around this

Of course it will, so the question becomes "why drive away Firefox when it works fine"?

we all know the answer

Because Firefox has such a small market share that it isn't worth spending the resources to support it.

How is adding a thing that complains that the user is using Firefox less resources spent than not doing it?

Adding the thing that complains is a one-time cost. It may work on Firefox now, but making sure that it continues working on Firefox is a continuous resource investment.

And not adding it and not testing for Firefox would cost nothing, and currently improve the user experience - because it actually just works, as a lot of things just do.

But then what if a bug in their code that only affects FF goes unnoticed due to testing, and causes significant problems for a big client, or a journalist reviewing it, or...

Personally I feel a "We don't officially support this browser, it probably works but we only test for full compatibility in <these browsers>" is a better option if you're going to go in that direction.

But I can understand why even that is a bit of a risk as if a user decides to ignore that warning and then some time later encounters a bug that, let's say, causes them to lose half a day of work, they're likely to walk away blaming the company (and maybe go round telling people they know what a shit thing it is) even if the bug wouldn't have happened had they been using one of the browsers that is fully supported and gets tested.

It seems more like the devs at MS know their code works on Firefox but have been asked by exec to push chromium(-esque) because edge is now webkit.

sidenote: this is a multi-billion $ company, no excuse to ignore any platform with their capacity, front face it looks like they can't build a good app anymore, especially if it works anyway with a simple string change in the browser - heck, web devs had to factor in ie7-8 polyfills built by the community only a few years ago. no excuse.

I recall that the advice given to web developers for a long time was to query browser capabilities instead of relying on a user agent string. If this site is indeed relying on the user agent string, I don’t get why larger companies which probably have better capable teams resort to this.

So sick of sites doing this. Labelbox even does it! Absolutely absurd.

Works for me(tm). No, really - I just navigated to the page with Firefox 103 on Wind10/64 and just got a normal website for the editor, with download links, videos, etc. Nothing about me needing to use a chrome based browser. Maybe they changed this?

I don't see the message until I click the "Try for Free" button.

Same for safari indeed.

Not supporting Safari is understandable for personal/toy project because you can't as easily test Safari without buying some Apple kit – whereas I can run Firefox, Chromium based browsers, and so forth, on my existing PCs and phones, in VMs if I want to check different OSs for odd differences.

Not good from though for, as in this case, something from MS.

And I don't block Safari, I just consider it a third class citizen when it comes to what little time I have to give for support.

I went down the rabbit hole of trying to connect to iOS Safari’s web inspector from my Linux machine last week. From the trail of activity on GitHub it looks like it might have been possible during about 2015–2020 but the open source adapter has since been effectively abandoned, with too few people doing the necessary ongoing maintenance. I spent a while trying to do it myself but it requires a deeper understanding of WebKit and Chromium internals than I possess.

Reply on news.ycombinator.com