mconley

TL;DR: Windows Defender had a bug that made certain system calls expensive on CPU cycles when Defender's Real-time Protection feature is enabled. After discovery, Mozilla reported this issue to Microsoft. Microsoft is releasing a patch that should result in lower CPU usage when using Firefox on sites like YouTube (a ~75% CPU usage reduction was noted when browsing YouTube in Firefox with the fixed version of Defender).

It seems like the HN submission form truncated the # from the end of the URL I linked to, which linked to the relevant comment. I'll try that here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1441918#c82

and

https://bugzilla.mozilla.org/show_bug.cgi?id=1441918#c91

As the article mentions, Firefox is not currently implementing the Picture-in-Picture Web API that you linked to. Firefox's implementation is a browser feature only, and not exposed to the web at large.

> They are simply no longer willing to disrupt the status quo, even to help their users.

This is just false.

I guess you're not aware of the content blocking work we've been focusing on lately?: https://www.theverge.com/2018/8/30/17800714/mozilla-firefox-...

Disclosure: I work for Mozilla on Firefox. I can say, without hesitation, that we definitely give a damn about protecting the user and protecting the health of the web.

This title is inaccurate. Mozilla is _not_ hiring a developer to work on Thunderbird full-time. See below:

From the post:

" The Thunderbird Project is hiring for a software engineer!

...

Please note that while the Thunderbird project is a group of individuals separate from the Mozilla Foundation that works to further the Thunderbird email client, the Mozilla Foundation is the Project’s fiscal home. The Thunderbird Council, separate from Mozilla, manages the Project and will direct the software engineer’s work."

Hi! Firefox engineer here. Check out this reply: https://news.ycombinator.com/item?id=15371068

If you're interested in helping me figure out what's going on here, feel free to send me a performance profile.

Hi! Firefox engineer here, and I want to understand why your Firefox is misbehaving.

Would you be willing to provide us a performance profile? Instructions are here: https://developer.mozilla.org/en-US/docs/Mozilla/Performance...

Feel free to email it to me if you don't want to post the link publicly. I'm mconley at mozilla dot com.

If you enter customize mode, you can:

1) Choose one of the compact themes, which have square tabs instead of curved

and

2) Re-enable the title bar

> * Mozilla: Nothing.

Really not sure what you're talking about here.

Along with this blog post: https://blog.mozilla.org/blog/2017/07/11/defending-net-neutr...

There's a snippet on about:home about Net Neutrality for every Firefox user:

https://ffp4g1ylyit3jdyti1hqcvtb-wpengine.netdna-ssl.com/wp-...

We've got a form here to make it easy to submit your comments to the FCC: https://advocacy.mozilla.org/en-US/net-neutrality-comments

We even voiced 9hrs worth of Net Neutrality comments that had already been submitted: https://www.youtube.com/watch?time_continue=1&v=twksX_S3vkg

The most recent episode of the IRL Podcast is centered completely around Net Neutrality: https://irlpodcast.org/episode2/

All good. Thanks for checking. :)

Please cc me too. (mconley at mozilla dot com)

> This is because the Mozilla Foundation refused to accept the Tor Project's commits to enhance privacy in the browser.

Actually, I'm pretty sure this is untrue. I'm reasonably certain we're actively working with the Tor Browser developers to get their patches merged into core (but preffed off) so that they don't have to maintain a stack of patches on top of Firefox.

(Disclaimer: Mozilla employee)

> What sets Apple apart from Googles and Facebooks is that it's the only company that stores the data in way that Apple itself cannot read it.

FWIW, Mozilla does the same thing for Firefox Accounts sync data - it's an opaque blob that we couldn't decrypt even if we wanted to.

(Disclosure: Mozilla employee)

Review Board works with GitHub and allows you to publish your review when you're ready.

> But people donate, and the people living off that money choose arbitrarily to spend those resources on IOS, that is just plain irresponsible.

Note that when people donate, they're donating to the Mozilla Foundation, an entity that does _not_ work on Firefox directly, but does advocacy, outreach and education work. This is where your donation goes.

Mozilla Corporation (which is solely owned by the Foundation) works on Firefox (Desktop, Android, iOS, Focus, etc), and does not benefit from the donations that are sent to the Foundation. That work is funded almost entirely by revenue generated by partnerships with search providers.

People who want to donate to the corporation do so via patches, bug reports, testing, documentation, evangelism, etc.

(Full-disclosure - I'm a Mozilla Corporation employee, but speaking for myself and not on behalf of the company)

contributor/employee at Mozilla here. Thank _you_.

Electrolysis ("e10s") has been enabled by default on the Nightly and Developer Edition* channels, if you'd like to help test it.

* Although we're currently running an A/B test to measure performance differences with e10s enabled and disabled, so you might fall into the disabled cohort when you run Dev Edition. This experiment is scheduled to end in a few days.

That blocksite looks pretty annoying, but according to our Add-on Dev Relations Lead (jorgev), since the tracking in blocksite is "opt in", it doesn't actually violate any of the AMO policies.

Note that I haven't actually installed the add-on or looked at the source[1], but just echoing what I'm reading in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=903799

"Add-ons should not be allowed that much power" - this is tricky. We want add-ons to be powerful enough that users can customize Firefox to their liking down to the tiniest detail. And yet, we want to make sure that the add-ons are not doing completely evil things to your machine.

Our solution to that problem is code review and static analysis of add-ons that are submitted to AMO. For add-ons that you install outside of AMO... well, you're on your own there.

It's tricky. We do very much want to make the browser safer for our users, and eliminating evil add-ons is high on our list of priorities, but there's a lot of stop energy put against our solutions[2].

I'm not in charge of add-ons, but I the predicament is clear. Add-on authors want the power to make the browser do amazing things. Users want add-ons to do amazing things. Bad actors want add-ons to do evil things. We want to protect the user, but we also want to respect the user's right to do or install whatever they'd like on their machines.

It's a fine balance.

[1]: Which is something our AMO editors do - they review the source of all add-ons that go up to AMO.

[2]: https://blog.mozilla.org/addons/2015/02/10/extension-signing... is one solution we're going after. Check out the comments for some of the fors and againsts.

(Full disclosure - I'm an engineer that's working on multi-process Firefox).

> Add-ons come in two flavors, "old" and "new" (Jetpack). This feature is only available to "old" add-ons. The direction with Firefox has been to narrow what add-ons can do.

This is false.

SDK (Jetpack) add-ons can do everything that "old" add-ons can do. The SDK just offers nicer APIs to allow add-on authors to do common things, and adds a layer to help protect add-on authors against changes in Firefox's code-base (the SDK has very strict deprecation policies, for example). Another advantage of SDK add-ons is that, if all goes well, very few (if any) SDK-based add-ons will need to be changed in order to work in multi-process Firefox. The SDK API layer will change to accommodate multi-process, and SDK-based add-ons should "just work".

js-ctypes, which this blog post talks about, is very much accessible from SDK-based add-ons[1]. SDK-based add-ons can also get direct access to the same old-style XPCOM components that power "old" add-ons[2].

Nothing about the SDK makes those add-ons weaker - if anything, it makes them more resilient to change.

[1]: Here's a simple SDK add-on I wrote to quickly crash the selected tab in multi-process Firefox: https://github.com/mikeconley/tab-crasher It uses js-ctypes to dereference a null pointer and segfault the content process.

[2]: https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_AP... - but note the "unstable" header, since the interfaces for these components are not frozen, which makes add-ons that use them more prone to incompatibility across Firefox versions.

This was not intentional. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1136300.

You might enjoy http://codefirefox.com/.

> I've never seen anyone dig through VCS history to gain a better understanding of code.

I'm actually going through the ancient CVS history of Mozilla Firefox in order to learn about a relatively poorly understood piece of code that's still in there to this day:

http://mikeconley.ca/blog/2014/07/07/docshell-in-a-nutshell-...

and

http://mikeconley.ca/blog/2014/08/10/docshell-in-a-nutshell-...

Viva la resistance!

Hey, post-author here.

I would argue that they're not non-essentials. They may not be functional essentials, but they certainly add to the experience of running a polished, smooth browser.

You'll be happy to note that I've been loaned out to the Electrolysis team. We're making headway on that front for Desktop, and you can already test it on Nightly[1]. Open up a copy of Nightly, and go to File > Open new e10s window. A new window will open that has its tabs use child processes (you can tell when this is working because the tab's title will be underlined).

We hope to enable this by default on Nightly in the near future.

[1]: http://nightly.mozilla.org/