Hacker News Reader

Comment by 0x002A | Hacker News Reader

"Because all network requests go through one socket thread, this loop blocked any further network communication and made Firefox unresponsive, unable to load web content." Why side functionality (telemetry) of a tool uses only one network thread and can block any network communication ?

View on HN

Per elsethread, supposedly any site could have triggered the crash, not just ”side functionality”: https://news.ycombinator.com/item?id=30175916

Yes that's another issue. But as a design pattern shouldn't we design our products to do their core functionality as much as independent from any anomalies that can happen? This is almost akin to me if Tesla rolls out an update and the car decides to pull over to the curb to do the update, while you are driving to your job or worse to hospital with an emergency. My theory is there should be at least one health enterprise using firefox as their only browser for business functionality out in the wild.

> But as a design pattern shouldn't we design our products to do their core functionality as much as independent from any anomalies that can happen?

When expected anomalies happen, like telemetry being down or taking a long time to respond. Firefox is certainly already designed like that.

This was not that. This was a bug. There is no magical design that avoids bugs.

> This is almost akin to me if Tesla rolls out an update and the car decides to pull over to the curb to do the update, while you are driving to your job or worse to hospital with an emergency.

Firefox is not a car. You're going to have to get Mozilla a lot more funding if you think the browser should be designed with extreme resilience in mind as required for life-critical applications. If a health enterprise is using Firefox in a life-critical role, that's kind of their responsibility, not Mozilla's.

In theory, that's how it happens in Firefox. But when you have a bug in the core of the product (the network stack), there isn't much that the rest of the product can do to isolate from it.

Yes that's what you get when you have one thread for all network communications. The network stack did not fail, only the sole network thread got stuck. From the write up I understand if there was another thread for communications firefox would only fail to communicate with telemetry service but firefox would be able to function as users needed.

Well, it could have limped along with degraded performance. Which would undoubtedly have been better.

I think that part is clear in the document.

"This is why users who disabled Telemetry would see this problem resolved even though the problem is not related to Telemetry functionality itself and could have been triggered otherwise."

It was a bug. It can't block network communication normally. It's not like telemetry serializes with normal user traffic. It was just a stupid infinite loop that broke what otherwise would've certainly been nonblocking multiplexing of requests.

I'm not saying this was actually a good design, for obvious reasons, but one decent reason to do it this way is so things like proxy settings are shared.

The socket thread does not do blocking reads.

Reply on news.ycombinator.com