This is the Lindqvist and Weller paper: https://link.springer.com/article/10.1007/s43630-025-00743-6

about:memory will let you generate a report that tells you what the memory is being used for.

Or about:performance, for a less detailed but arguably nicer quick overview.

What web apps do you use that use the File System Access API?

It's being actively worked on: https://bugzilla.mozilla.org/show_bug.cgi?id=1838746

Which of those tests do you feel best measures smoothness?

All of them, I guess. I don't/won't use FF anyway, so...

What parts felt unresponsive and slow?

Why is that bug important to you?

When you build a phone and want that phone to work with salesforce classic- every time a page reloads. You must put the WebRTC in a pop out window. This window will not have focus because they are in salesforce . Even in lightning people want a pop out for the call. Firefox is broken

This seems incredibly niche, to the point I still don't fully understand what exactly your use case is.

Salesforce has over 150,000 companies using it's platform, with estimates around 150 million users... The percentage that use OpenCTI powered by five 9, ctm, gensys, twilio, telnyx, etc... that are WebRTC based if even let's say 10%... that is still like 15 million users daily... not exactly niche for Firefox to be breaking a feature for that many users? Oh and consider that salesforce method for embedding a phone is fairly common, then you have other CRM's zoho, hubspot and customer service platform zendesk etc... all broken with firefox's position on WebRTC...

I'm with the other responder, it is not clear at all to me what you even desire here. I'd say the first step would be to concisely and clearly formulate a way to explain what you are complaining about.

WebRTC is broken in Firefox. Firefox team thinks to keep you safe we must break the media stream connection the instant the window loses focus.

I use BigQuery studio often in Firefox and haven’t noticed anything being worse than Chrome. What problems do you see?

I recently had cause to sign in to the Google Cloud console (not BigQuery specifically) and found it unusable on Firefox. It pegged a core at 100% and consumed memory at a prodigious rate. Basic UI actions were painfully slow.

I killed the tab and tried it in Chromium where the UI was... not snappy, but in range for my expectations of a heavyweight frontend.

Yeah, I use Chromium for anything Google made, and FF for everything else. Google makes sure that their pages work sloooowly on Firefox (e.g. Google Earth). No such problems elsewhere.

I use it all the time on multiple platforms and it is a DOG on anything but Chrome/Chromium. We have 30+ datasets each with many tables/views/functions etc tho so that could be part of the issue.

Same thing will happen in the billing portal or really any experience but I notice it the most in BQ.

How does the implementation compare to RR?

We are building our future support for the system languages for now directly on top of RR recordings: credit to Robert(roca) and Kyle and all other contributors for RR and Pernosco, they're amazing technologies.

We've researched possible alternative approaches/tools as well, especially keeping in mind Windows/Mac support.

The traces for Noir and the scripting languages work in a completely different way, capturing all the relevant data which is later indexed into a db-like structure. With some future optimizations this can be very useful for various shorter programs in scripting languages, and generally for blockchain languages(as the running time there is usually low) and we hope that eventually with flexible record filtering it can be practical even for capturing important segments/aspects of long-running real world projects.

I thought the sea-of-nodes choice was interesting.

V8 has been moving away from sea-of-nodes. Here's a video where Ben Titzer is talking about V8's reasons for moving away from sea-of-nodes: https://www.youtube.com/watch?v=Vu372dnk2Ak&t=184s. Yasser, the author of Tilde, is is also in the video.

TL;DW version: sea of nodes requires a scheduling pass, which was taking 20% of their compilation time. But it sounds like there's a lot of legacy baggage, so ...

My GCM doesn't take 20% of my compile times last I checked but even so, V8 is gonna be in a special camp because they're comparing against a compiler that doesn't do much code motion. LLVM does a lot of code motion so that "20%" is still being paid by LLVM during their hoisting and local scheduling passes.