Hacker News Reader

Comment by seism | Hacker News Reader

It's an open source project, with a good discussion of the technical issues on GitHub[1]. Probably linked to certain user behaviors, like having hundreds of tabs open, but surely also contingent on the complexity of wedging a browser in iOS. Like maneuvering an excavator into a sandbox.

[1] https://github.com/mozilla-mobile/firefox-ios/issues/12113

View on HN

I also wonder how these requests "beat the shit out of the web server." It's requesting the feed and the favicon, both of which could be cached by a CDN. Even if they aren't, how much traffic are you gonna see from this compared to some other page trending on HN? Wasteful, sure, but hardly that big a deal

> Wasteful, sure, but hardly that big a deal

This attitude is why so much software is garbage, and why people with limited connections or hardware can't have a good time on the internet.

In this case, using a CDN in front of the server is the thing which would improve things for people with limited bw/hw more quickly and to a greater extent than counting the fetches by Firefox on iOS and calling it out for fetching too much

But if clients were considerate, we wouldn't need to waste electricity and work hours to run CDNs?

You would want a CDN anyway to cache data across users, on servers close to those users, cutting the time & energy spent to serve the data.

I feel like this is a marketing meme by cdn providers that gets parroted a lot. As someone who has used CDNs vs hosting on the server directly, CDNs are slower to load the images especially when there is a cache miss. The only reason I’m using a cdn is because I need to host 100gb+ images. If it wasn’t for that I wouldn’t use a cdn and get a better experience on the site.

  >In this case, [X] would improve things more quickly than [Y].

Maybe so, but more importantly why are you phrasing this like it's an either/or choice?

"We, the developer community, contain multitudes." Clearly we can (and should) do both.

Besides the obvious benefits at the higher community level of organization, deploying both solutions will result in even less bandwidth and power wasted from this specific bug than using either solution by itself.

Why should you need to provision a CDN when If-Modified-Since / Etags exist?

I get that not every client is well behaved, but you'd hope that Firefox would be, given Mozilla's presence in web standards.

(Which, tbh makes me think this issue is the "on iOS" bit, given it's Firefox. I presume Apple still has their "only Safari's rendering engine" rule in place for... ...reasons)

A CDN caches across users, lowers latency by having servers closer to the user, and lowers the bandwidth your server needs to handle. Cloudflare CDN has a free tier and I assume others do, too, so it's fairly easy to provision.

Why would the issue be “on iOS”? The renderer has nothing to do with how pages are fetched.

They probably have to write a totally different fetching logic for the Safari wrapper. If Apple wasn't as scummy as they are, they would have used the same logic as in other platforms where this problem doesn't seem to exist.

Because Apple.

Bad take.

I opened the Github issue linked. For us it represented, at times, thousands of requests per second across multiple users. And that was with affected users getting IP-banned temporarily.

Some of which were 404s which you typically absolutely do not want cached. Or 405s (on HEAD /favicon.ico for example). Or 429s. Or 403s.

Browsers are expected to: 1. Use the favicon specified in meta if any (we do have one, /favicon.svg) 2. Respect cache headers (immutable + multi-months max-age) 3. Not make completely random requests to things they should ignore (such as OpenGraph tags)

Yes CDNs do help with these kinds of issues, but they absolutely do not fix them all. Which is why even though we have a pretty damn elaborate setup in that regard we were being annoyed by the issue.

But also Firefox on iOS should be not-completely-broken.

Pretty weird to think that running a web server also means you should operate "a geographically distributed network of proxy servers and their data centers".

I also think it's pretty weird to defend thoroughly defect software with "waste ful, sure, but hardly that big a deal".

404s don't get cached. At least I don't configure anything to cache them.

> A 404 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls

— https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.4

This why in a lot of contexts it would be good to at least be micro catching them. If they were cached for 5 seconds it would have covered all subsequent requests.

404s have got to be very cheap to serve

Not when you're on a metered connection, or on a high latency one.

Don't make your customers pay for your sloppy habits is a good policy to have.

If the CDN returns a 404 or the origin server, then your satellite phone is still waiting.

But they aren't always!

I can easily have hundreds of Chrome tabs open, and none of this happens. I can have hundreds of tabs inadvertently open in iOS Safari, and none of this happens.

Would you kindly refrain from blaming users for what clearly is a bug in the application?

Hell, I have hundreds of tabs open on firefox on my android phone, and none of this happens.

Also, when I saw the headline, I had to think of all the LLM scrapers and bots (soon to be running directly on your AIphone!) roaming the Interwebs.

Just yesterday I blocked the bots from my blog using this[1]. Of course whether these bots respect robots.txt nowadays is a different question altogether

[1]: https://github.com/fardog/fardog.io/commit/b2e3eac838ea25209...

They do not: https://news.ycombinator.com/item?id=40759916

I thought all browsers on iOS were using the apple browser engine and ditto for Android.

That is, they are just skins

They are using the WebKit rendering engine, but there’s a lot more to a web browser than just its rendering engine. They aren’t just skins.

Could you add a more to that? What other complex parts are built by FF?

Why the “complex” qualifier? The code responsible for the incorrect favicon URL bug is very simple, and part of the Firefox codebase not WebKit:

https://github.com/mozilla-mobile/firefox-ios/blob/bd589c194...

Firefox on iOS has about 200k lines of Swift. As a rough rule of thumb, everything that isn’t directly related to rendering something within the page or executing JavaScript is Firefox code not WebKit code. So bookmarks, syncing, tabs, etc.

Not necessarily complex, but the tab switcher etc is built by Firefox, and probably is what tries to load the favicons to display the icon somewhere?

What do you think is complex?

Yea, that's basically it on iOS, although there is a bunch ux, so it's not nothing

On android, browsers can ship their own engines, and they do. There is actually some freedom on android.

This changed very recently due to EU rules

Reply on news.ycombinator.com