Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firefox 84.0

mozilla.org

Post reply on HN
Print view View original

151–160 of 328 posts

Re: Firefox 84.0

#151

Post by cpeterso »

Macha wrote: post #128
cpeterso wrote: post #117

Earlier quoted context omitted.

You can install any add-on from addons.mozilla.org in Firefox Nightly for Android: https://blog.mozilla.org/addons/2020/09/29/expanded-extensio...

Right, but choosing between power user features and stability is clearly worse as a user than not having to choose between power user features and stability. Also isn't there more telemetry on by default in nightly?

Installing unsupported add-ons also risks instability. Mozilla didn't restrict the initial list of supported add-ons because they don't want to allow add-ons. They continue to expand the list of add-ons supported in Firefox for Android as more add-ons and APIs are tested.

Mozilla uses Firefox telemetry to fix bugs, identify areas to optimize, and guide product decisions. How else can Mozilla know which devices or problems to prioritize?

Re: Firefox 84.0

#153

Post by saagarjha »

est31 wrote: post #138
jcranmer wrote: post #132

Earlier quoted context omitted.

My memory may be faulty, but my recollection is there was never a serious attempt to replace NPAPI with Pepper. It was looked into, but it was concluded that the Pepper APIs were too tightly bound to Webkit's implementation to make it possible to implement, and Mozilla instead built their own out-of-process sandbox (which was sorely needed because Flash crashes were the single largest cause of Firefox crashes).

This is the project I was referring to: https://wiki.mozilla.org/index.php?title=Mortar_Project&oldi...

Chrome has deprecated Pepper, hasn't it?

Re: Firefox 84.0

#154

Post by larrik »

> The Network panel is now able to handle unexpected crashes and render useful debugging details such as a related stack-trace. Users can also easily file a bug report by clicking on the available link to help improve the stability of the tool.

Does this mean it will actually work on initial page load? Pretty annoying that a new tab requires loading the page twice with devtools open...

Re: Firefox 84.0

#155

Post by dralley »

foepys wrote: post #66
bryanlarsen wrote: post #44

Earlier quoted context omitted.

Firefox is way too valuable as a hedge against Google hegemony to let die. If they ever lose the Google search money hose and become threatened I do expect a Google competitor to realize that and step in with some funding. Microsoft basing Edge on Chromium was a really stupid move on their part for this reason, and I suspect they are starting to realize it. That being said, I only expect it to be maintained at a hedg…

Isn't the reason why many applications and libraries use Chromium due to Gecko's too Firefox-centric APIs? I read a post here on HN a few months (years?) ago where a developer was really trying to use Gecko for their own application and got frustrated so much that they gave up and switched to Chromium.

Gecko is architected to be used as a framework, not a library, which means it tries to dictate a lot of aspects of how your code is supposed to be structured. Whereas Webkit/Blink is the other way around.

It predates KHTML/Webkit by several years so some additional legacy baggage is to be expected.

Re: Firefox 84.0

#156

Post by faitswulff »

bryanlarsen wrote: post #44
chinhodado wrote: post #11

I love Firefox, I use it everyday, I can't imagine using a browser without Tree Style Tab, or all the things that I can do in about:config. At the same time, I can't shake off the dreadful feeling that it will eventually die one day. The market share keeps falling year by year. What is the most realistic future for Firefox?

Firefox is way too valuable as a hedge against Google hegemony to let die. If they ever lose the Google search money hose and become threatened I do expect a Google competitor to realize that and step in with some funding. Microsoft basing Edge on Chromium was a really stupid move on their part for this reason, and I suspect they are starting to realize it. That being said, I only expect it to be maintained at a hedg…

What makes you suspect Microsoft is starting to regret basing Edge off of Chromium?

Re: Firefox 84.0

#157

Post by abdullahkhalids »

IshKebab wrote: post #131
xyzal wrote: post #34

Earlier quoted context omitted.

I can't understand why they still didn't put a "Support Mozilla" prompt anywhere.

It would be complicated due to Mozilla's structure. Mozilla Foundation is a non-profit that owns the for-profit Mozilla Corporation. You can donate to the foundation but they can't use the money for Firefox. But the fundamental reason is that donations are only ever going to be a drop in the ocean. Google gives them $400m/year. Mozilla Foundation donations are like $3m/year. Even Wikipedia donations are only about $1…

What's preventing the Mozilla Corporation from selling "e-merchandise", like a sequence of themes for $1, $5, $10, $100, etc, to raise money?

Re: Firefox 84.0

#158

Post by slenk »

blindm wrote: post #3
easton wrote: post #2

Notable changes are that Apple Silicon support is now stable, and that this is the final release of Firefox to support Adobe Flash.

And if you sorely miss Flash, you can run it with Ruffle: https://ruffle.rs/

I will have to keep that in mind. A lot of old management interfaces for rack-mount servers run flash for their web interface :S

Re: Firefox 84.0

#159

Post by phs2501 »

bzb6 wrote: post #77
blindm wrote: post #3

Earlier quoted context omitted.

And if you sorely miss Flash, you can run it with Ruffle: https://ruffle.rs/

I tried it on archive.org and it’s not that good. https://archive.org/details/flash_badger On Chrome the animation starts lagging behind after a few loops so audio and video desync badly. On Firefox it’s much worse, since Firefox is naturally slower than Chrome so even the first loop is desynced already.

IIRC (it's been many years) after many loops that animation started desyncing in the real Flash player too. It wasn't terribly noticeable after only a few loops, but the fact that it happened made me think that the audio loop was completely async from the animation.

Re: Firefox 84.0

#160

Post by est31 »

pimterry wrote: post #150
est31 wrote: post #107

Earlier quoted context omitted.

I think it's a problem from a security point of view to allow websites to do this. Often the server that runs on localhost is poorly secured and may even expose "Access-Control-Allow-Origin: *" headers. And even if it doesn't, the browser still has to run a request to find out whether such a header is present, so some attacker controlled data does end up in these services. This in turn can be used for attacks. Maybe…

Yes, it's possible localhost servers can have security issues, but: * This only affects servers that do indeed serve the "anybody can talk to me" CORS headers. For anything else, standard cross-origin restrictions apply. A simple localhost server that has ignored this issue and isn't aware of CORS at all is generally not vulnerable. * This change doesn't actually increase this risk, it decreases it! Localhost request…

> This only affects servers that do indeed serve the "anybody can talk to me" CORS headers.

Again, even if these CORS headers are not sent, the browser still does a request to the server in order to find out whether the headers are being sent. Check running python3 -m http.server in your terminal, and then do var v = fetch("http://localhost:8000/hellllllo") in your browser's console. You will get a big red CORS error in the console, because the builtin python http server does not send these headers. But the web server will still receive and respond to the "hellllllo" GET request! It will show up in your terminal's log. For some insecure servers, getting a specifically crafted request might be enough to exploit security bugs. Like I said, take a server that has a limited size buffer for the URL after which it overflows letting you write data to whatever is beyond that on the stack.

> This change doesn't actually increase this risk

Alright you have a point here, but it's still bad this feature exists in the first place.

> This is a pretty common pattern for lots of popular software that has a desktop component

Because it's used doesn't mean it's a bad idea.

> There's ongoing work to restrict this further

Huh that's very nice. Indeed this would resolve my concerns:

    In the future, whenever a public website is trying to fetch resources from a private or a local network, Chrome will send a preflight request before the actual request.
Preflight requests are hardcoded and barely have any attacker controlled data (except for the ip address maybe, as 127.0.0.2 is as valid as 127.0.0.1).
Post reply on HN