dblohm7

The two companies I miss most are Phar Lap and NuMega.

(I used to work on the Android port of Gecko for Firefox)

That was never a thing.

Former Mozilla engineer here.

> I observed the change in tone in Mozilla blog posts, from experts talking about their craft to marketspeak.

I think I can explain what you're seeing here. The original blog.mozilla.org was run very much like the old "MSDN blogs" from Microsoft (think Raymond Chen's The Old New Thing.)

When I started at Mozilla a decade ago, my manager told me to file a request for my own space on blogs.mozilla.org -- which was denied. I was told that this was because blog.mozilla.org was being refocused as the "official" Mozilla blog.

People who already had accounts on there were grandfathered in, which is why some people (Nick Nethercote's blog come to mind) still had blogs on there. Obviously as those developers moved on, those employee blogs have gradually died off.

These days, if you want technical content, you'll need to look at hacks.mozilla.org for "officially sanctioned" pieces, or look at the blogs that publish to planet.mozilla.org for developer blogs (though much like blogging in general, there is much less traffic on there compared to a decade ago).

TL;DR: The focus of blog.mozilla.org is primarily corporate and marketing at this point.

On Windows ULONG_PTR is not an unsigned long*, it is a pointer-width unsigned integer.

LONGs and ULONGs are 32-bits on 64-bit Windows, so when porting the API to 64 bits, types that were typedef'd as such on 32-bit, but actually need to be 64-bits wide on 64-bit systems, were replaced with ULONG_PTR.

When I worked on Firefox for Android, we were constantly fighting for the broader Firefox org to take mobile more seriously —- if Gecko excelled on mobile with respect to power consumption, then a lot of that would spill over to desktop platforms “for free.”

Unfortunately nothing had improved by the time I left in 2021.

Removing XPCOM is orthogonal to adding rust. In fact, if you search Bugzilla you fill find many references to deCOMtamination, which is about removing unnecessary XPCOM.

Former Firefox developer: It was both.

Former Firefox developer here.

The reason for omitting tests is because they are essentially the exploits themselves; omission raises the barrier to entry, as somebody has to be skilled enough to craft an exploit based on the source code change.

While security fixes are typically pushed out on all supported branches within a very short window of time, anything that buys time is useful imho.

You're precisely correct, IMHO. I use Windows on my desktop primarily because I don't have the patience to deal with (2).

> It's sad that Firefox engine is so difficult to embed and we could have seen more projects using it.

Not on Android, it isn't. https://geckoview.dev

Former Mozilla engineer here: The Firefox team isn't as small as you are implying, and they are always constrained by inadequate resources.

Former Mozilla employee here: A subset, yes, but also a majority. And it isn't enough.

Former browser engineer here: Thank you for that second sentence. So many people forget that part!

Given the projects where Rust is already in use (and has been for several years at this point), I don't think that is a concern.

(Personal opinion here) Keep in mind that we're still a relatively small (but growing) team, and I think that a big part of not open sourcing everything is a simple matter of having the capacity to properly engage with the community.

For now, we've optimized for doing that for operating systems where users most expect it.

Tailscale employee here:

In general the OSS operating systems get OSS clients, whereas the closed-source ones don’t necessarily get the full OSS treatment.

Ah, so it is! I got overexcited because I was one of the people who advocated for a racy cache during the redesign of that code back in the day.

When the cache wins the network transfer is canceled, so it’s not as bad as you’re making it out to be.

Firefox's HTTP cache races with the network for precisely this reason.

> A primary reason why I left is that I felt like my wings were clipped as PM, and that I was unable to effectively build symbiosis with engineering.

I feel this hard. On the occasions that I tried to reach out to product management about things that, for important technical reasons, weren't going to work, I was more or less blocked by director-level management and told that I was being mean to my colleagues for wanting to provide that kind of feedback.

Yes. It was an intractable problem.

Yeah, but what's the tablet market for Android these days?

Or you know, we just wanted to offer the closest thing we could get to continuous delivery of desktop software?

No.

> that's why they've killed XUL

We couldn't deliver a multiprocess browser without doing it.

> about:config for the android version

I completely supported this and continue to do so. GeckoView on Android works completely differently than desktop Firefox, and about:config's semantics are not identical between the two. A few of us were interested in offering an alternative that gave users a way to make adjustments in a way that was "safe," but as you can imagine that has never been a management priority.

This is correct. Full-time devs are going to spend their work time on what the people who pay them tell them they should be working on.

That's fair, I think in GV at the time we were more thinking about Fennec parity, so that's where my thoughts originate.

IMHO: Product managers are super important: it's their job to understand the market (where it was, where it is, and where it is going), the competitive landscape, and work with leadership on strategic planning.

However, all three groups (UX, PM, Eng) need to work symbiotically. Everybody needs to be sharing information and acting as partners in the work they're doing.

My 2 cents: One of the reasons why I left is that there was no longer any symbiotic relationship between product management and engineering. Product makes unilateral decisions, throws them over the wall, and engineering is expected to quit whining and just do what they're told.

(Former Mozilla developer here, who worked on GeckoView[1], the modern way to embed Gecko into Android apps, including all currently shipped Mozilla browsers on Android)

From an engineering perspective, the sad thing about this is that the work to finish extensions in GeckoView was essentially completed in the months after the initial Fenix release.

When GeckoView was still being rolled out into release, we understandably wanted to restrict the selection of addons only to those that exercised APIs that we knew were ready for production. Since that time, however, the WebExtensions work was essentially completed -- since that time it has entirely been a business decision to continue restricting the selection of addons available.

I didn't personally work on the WebExtensions bits, but I know that those who did were frustrated that their work to finish fleshing out full extension support was being held back for seemingly arbitrary reasons (that were never explained to engineering).

[1] https://geckoview.dev

One aspect of these forks that never gets mentioned:

It's great when a fork ensures that it is always taking security patches from upstream. But what about the code unique to the fork? Is that new code following the same security practices as the upstream project? Are enough eyeballs poking at it to get it the same security scrutiny as upstream?