Hacker News Reader

Comment by 2Gkashmiri | Hacker News Reader

as a person whohas exclusively used firefox all my life, even on my android, i have both firefox and focus, this is quite good news.

the only problem i can imagine is the invisible pressure by the unending desire to become chrome,you know with hiding the search bar by default "because people are used to that from chrome" and other shenanigans, i feel this support might be shortlived because the stupid people managing firefox are paid by google to fuck up firefox in the worst possible way and this just feels another attempt in that regard.

btw, i've been online since 2004, daily so i have used a lot of firefox

View on HN

I was saddened recently when I learnt they changed "View image" to "Open image in new tab". I loved the way "View image" worked, allowing you to maintain the image in full view while preserving tab history. If you wanted to open it a new tab, you could middle click it or ctrl click it. But since users were used to the Chrome behaviour they changed it to match, and thus Firefox lost a functionality. Unfortunately, since this is such a niche use case, Mozilla has little incentive to restore it. (Note: Extensions that restore the context menu item fails when the image loading relies on the REFERER header, since it actively re-requests it.)

There are numerous smaller items like this, that just flowed a lot better, particularly if you're heavily browsing images, like tab previews, that have been sacrificed either in the name of performance or to be more like Chrome. Fortunately, SeaMonkey still maintains these classic features, but is unfortunately a memory hog.

My daily browser has also been Firefox since around 2004. SeaMonkey remains a time pocket, when I long for the old days of yore.

> sacrificed […] in the name of performance […] SeaMonkey still maintains these classic features, but is unfortunately a memory hog.

I mean, there might be a relation? I went from IE to Netscape (edit: Or NS to IE?), to Firefox to Chrome, then tried every 1-2 years to switch back to Firefox and always returned to Chrome because it was so much faster. It was only 2-5 years ago (can’t remember exactly) when FF switched to fully multiprocess and stopped using their unique extension model, that I could finally start using FF again because the performance was finally on par with Chrome.

I miss being able to long-press a link and clicking "send link to device."

Now it only lets you send the page you're currently on, which is annoying.

I send a lot of stuff to my desktop when I'm riding the bus.

use plasma integration to get that. it works 100% of the time

the thing that's been driving me crazy lately is that they got rid of the undo history for the search bar. if you submit a search, it resets the undo history to be more specific. I expect by now so few people use the search bar that this is probably not going to be fixed any time soon, sadly.

AFAIK that's because the new tab behavior keeps web apps' state intact. When the web was more static, opening the image in current tab was fine. But nowadays you'd just lose your place on an app-site so the new tab option gets you your image in full view but prevents bungling up the app.

I think along the same lines. Mozilla has forgotten a lot of the political fights of the past around freedom and customisation and instead focused on US partisan talking points supporting censorship and forgetting about the desires of core users.

I, too, feel that eventually they might just go: "Everyone is doing it and it cost us more effort to keep maintaining it, here you have our own internal blocking, which won't block Google related stuff because they fund us"

All I know is. It's my device. Not Google's and I intend to fight that battle, just like we did with Microsoft.

I doubt it, since this is an API, and not a visible difference. Seems that changes like that are mostly targeted at the UI.

I see that differently… my wife uses firefox and that API. She eventually replaced her laptop. The only problem was that the old one wasn't fast enough to process about 90,000 regexps each time she clicked a link.

Chrome replaced it with a less flexible API that has bounded runtime, preventing the browser from the kind of slowness that caused a certain dissatisfaction, even disharmony here.

You could say that people shouldn't configure so much adblocking that the browser has to evaluate 90,000 regexps for a simple click. Or you could say that the browser shouldn't prevent that case by design. It's not simple. IMO a worst case like this is one of the causes of "invisible pressure".

No well-known content blocker "process about 90,000 regexps" to find out whether a resource needs to be blocked or not, that's just not how it works internally.

Last time I ran benchmarks of all well-known content blockers using Ghostery's benchmark tool[1], all of them could process a network request under 20µs on average.

Some do have performance concerns, but it has nothing to do with network filtering, it has to do with other stuff they do beyond network filtering (for example see [2]) and declarativeNetRequest does not help there, so they will still suffer these performance issues under MV3.

---

[1] https://github.com/ghostery/adblocker/tree/master/packages/a...

[2] https://www.extremetech.com/computing/182428-ironic-iframes-...

I doubt that 90,000 rules were an issue. On 12 year old laptop (thinkpad x230) with 260,000 ublock rules (+240,000 cosmetic) the slowdown is imperceptible. Contrary, ad-ridden websites load much faster.

Disabling the blockers (plural because three) fixed it, so it was either that or that the extra processing pushed firefox over a RAM cliff and into swap, which sounds unlikely. Anyway, we didn't try any more debugging, she just got a new laptop.

You invented a problem and "didn't try any more debugging". Its like complaining about using three condoms, then changing partner to fix it.

Probably one of the extensions was the culprit. But clearly it's not about the number of rules and crippling that functionality would not bring performance benefit. Ublock origin is pretty lightweight even with 500,000 rules applied.

Most of those regexes fail after processing the first few characters.

I wonder if an optimizing regex-compiler could transform the set of regexes into a single finite state machine that’s more efficient than running individual regex recognizers in parallel. The optimal solution feels NP-hard, but I wonder if one could get sufficient improvements with some heuristic optimizations, like extracting common clauses, etc.

Maybe @burntsushi has some insights about this?

Taking a set of regexes and compiling them all into one automaton is exactly what RegexSet is: https://docs.rs/regex/latest/regex/struct.RegexSet.html

However, when you're talking about thousands of regexes, that's going to be a very large automaton. Probably impractically large. It's not NP-hard. It's "just" impractical.

Using heuristics to whittle down the set of possible regexes to match---likely using literals extracted from each regex---is exactly what you want to do for a problem like this. If all you have are literals, an Aho-Corasick automaton is feasible to build for 90,000 entries. Aho-Corasick, in my experience, doesn't really start to break down until you eclipse 1,000,000 entries.

Emacs used such a thing ~30 years ago. Common wisdom was that it was great when it worked, but a few carelessly written regexes would shoot the performance. If course there'll be some carelessly written ones in any set of >1k regexes.

Reply on news.ycombinator.com