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

181–190 of 328 posts

Re: Firefox 84.0

#181

Post by bzbarsky »

SCLeo wrote: post #126
jefftk wrote: post #9

And for developers: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel... The biggest change from my perspective is "Firefox now ensures that localhost URLs — such as http://localhost/ and http://dev.localhost/ — refer to the local host's loopback interface (e.g. http://127.0.0.1 ). As a result, resources loaded from localhost are now assumed to have been delivered securely (see Secure contexts), and also w…

So, does that mean things like WebCrypto (which requires https to be available) will work in development environment now? Or did they already work out of box? I never tried because I assumed they won't work.

Yes, that is exactly what it means: things that require a "secure context" in spec terms, like WebCrypto, will work on http://localhost even though it's not https.

Re: Firefox 84.0

#182

Post by noncoml »

> Firefox now uses more modern techniques for allocating shared memory on Linux, improving performance and increasing compatibility with Docker.

Anyone know any more details about this one?

Re: Firefox 84.0

#183

Post by muizelaar »

AshamedCaptain wrote: post #54
antouank wrote: post #4

> Additionally we'll ship an accelerated rendering pipeline for Linux/GNOME/X11 users for the first time, ever!

Wait... GNOME only?

Yep. We've seen bugs with different window managers so WebRender is only enabled in Gnome in 84 to minimize the risk of breakage. This restriction will be removed in subsequent releases.

Re: Firefox 84.0

#184

Post by est31 »

radlad wrote: post #170
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…

One use case is to allow secure authentication. For example, some software, such as VPN clients, will now open the authentication page in a Chrome/Firefox web browser, rather than in an embedded browser - this is a security win! It affords the ability to use WebAuthn/U2F, password managers, as well as an updated browser. However, for this to work, you need to pass an authentication token back to the client - this is…

Interesting points, thank you.

The cloud service could communicate with the local device's client through a separate connection though that the client opens with that cloud service, no need to do this via the local JS.

The only benefit I could think of would be that it makes it easier to correlate the local client with the authenticating user, but you could just have a token that you make part of the URL the client visits. Also it doesnt fully solve the correlation problem either, on the same computer, two clients could run under two different OS level accounts. Will it just send its authentication token to one of those clients? There is no user separation on Windows or Linux. I only know about Chrome OS having user separation at the port level.

Re: Firefox 84.0

#185

Post by rhizome »

nerdponx wrote: post #69
macspoofing wrote: post #37

Earlier quoted context omitted.

>This is great for local development. Not just. There is a niche for mixed web/native apps whereby the page is loaded from the web, but interacts (at least in part) with a locally hosted web-server.

Or even just browser apps that are easy/encouraged to run locally, like Jupyter Notebook.

Like, started from the local filesystem? I see they have a "Notebook Server," is that what you mean by "locally," rather than starting it from clicking an e.g. "jupyter.html" file?

To their credit, it doesn't seem to use Node, and configuration via .py files tells me maybe they have some lightweight server thing that makes it a bit more manageable as a single-user app than via Node or Electron and friends.

Anyway, I have a project I have been wanting to be completely self-contained in an HTML file, but that gives me CORS problems, so now I'm thinking maybe the Jupyter posse has implemented a nice compromise I can use.

Re: Firefox 84.0

#188

Post by cat199 »

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?

r.e. realistic - no idea

r.e. market share: one problem is developers - web-oriented devs who deal with node.js invariably must use chrome simply for the server-side devtools, and then stick with it, leading to 'only in chrome' sites and 'all the cool kids' / new developers using chrome..

would love to see a well-supported spidermonkey-based server-side JS engine, electron replacement, and corresponding firefox debug tooling

Re: Firefox 84.0

#190

Post by nerdponx »

rhizome wrote: post #185
nerdponx wrote: post #69

Earlier quoted context omitted.

Or even just browser apps that are easy/encouraged to run locally, like Jupyter Notebook.

Like, started from the local filesystem? I see they have a "Notebook Server," is that what you mean by "locally," rather than starting it from clicking an e.g. "jupyter.html" file? To their credit, it doesn't seem to use Node, and configuration via .py files tells me maybe they have some lightweight server thing that makes it a bit more manageable as a single-user app than via Node or Electron and friends. Anyway, I…

Yes, Jupyter Notebook (and its successor Jupyter Lab) is a Python program that serves a browser (HTML/CSS/JS) application. It is meant to be used equally well when the Jupyter server is on your local machine or somewhere else on the network.

Other tools that use similar architectures: Tabula, Kiwi IRC, The Lounge IRC. The user experience is maybe more "technical", but you don't have Electron involved, just whatever web browser you would use for anything else.

Post reply on HN