This is on macOS 10.15.6.

In my current main Firefox Nightly session, downloading a file causes 100% CPU usage in the socket thread.
Gecko Profile: https://share.firefox.dev/3fB3qVK
Instruments profile with kernel call stacks: https://share.firefox.dev/32kcmLm

A log from about:networking contains lots of instances of "timeout: none" and "timeout = -1 milliseconds":

2020-07-15 01:50:24.589145 UTC - [Parent 47556: Socket Thread]: D/nsSocketTransport poll timeout: none
2020-07-15 01:50:24.589151 UTC - [Parent 47556: Socket Thread]: D/nsSocketTransport     timeout = -1 milliseconds
2020-07-15 01:50:24.589538 UTC - [Parent 47556: Socket Thread]: D/nsSocketTransport     ...returned after 1 milliseconds

So we're passing PR_INTERVAL_NO_TIMEOUT, which should mean "block indefinitely".

Maybe poll on macOS is broken and doesn't actually block? It seems this wouldn't be the first time; this post from 2016 says:

The new error looks similar to the old problem: when there’s nothing to wait for and we ask poll() to wait N milliseconds, the 10.12 version of poll() returns immediately without waiting. Causing busy-loops.

but then later says

This poll bug has been confirmed fixed in the macOS 10.12.2 update

Logs please.

I'll upload some logs once I can reproduce this in a fresh profile.

I think it might have to do with the download speed as well. At 1.3MB/s I have around 35% CPU usage. Once my OS update is finished downloading, I'll try again. When I reported this bug yesterday, my download speed was 3.0MB/s.

I have not seen this recently. I still get high CPU usage during downloads, but only a small part of it seems to come from the PR_Poll call.