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

271–280 of 328 posts

Re: Firefox 84.0

#271

Post by sfink »

mrlala wrote: post #253

Since this is a firefox thread, I have a very annoying bug that I haven't had much luck searching on... any luck here? I really like the picture-in-picture feature of firefox. However, if I have a video in PiP mode and I click pause, randomly about 5-10 seconds later it unpauses and keeps playing. This happens on both Hulu and Netflix.. on multiple computers and has been going on for quite some time. Seems like such…

It is a common thing, so I'm guessing not many other people are experiencing it. I just tried with Netflix, and it doesn't seem to be happening for me. Do you have any unusual peripherals (that might somehow shift focus to the PIP window and send a space or something)?

It's certainly worth filing a bug over. https://bugzilla.mozilla.org/enter_bug.cgi

Re: Firefox 84.0

#272

Post by eeperson »

mormegil wrote: post #90
coldpie wrote: post #21

Earlier quoted context omitted.

I'm in the same boat and have the same worries. I give them a monthly donation to support the company, in hopes of showing that there are paying customers they may be able to fall back on in the future. I can't think of anything else I can do to turn back the tide of the advertiser-developed browser. (Yes, I already know the money doesn't go directly to Firefox development today, thanks.)

Thank you for this inspiration, I've created my monthly payment now. I cannot imagine being forced to use anything else than Firefox... (Even though the Android version is barely usable after the rework...)

> Even though the Android version is barely usable after the rework...

Yeah, the initial launch was pretty bad. However, this has improved quite a bit from the initial launch if you haven't tried it in a while.

Re: Firefox 84.0

#273

Post by Aperocky »

jacurtis wrote: post #31

Huge update for users on new Apple Silicon Macs: > Native support for macOS devices built with Apple Silicon CPUs brings dramatic performance improvements over the non-native build that was shipped in Firefox 83: Firefox launches over 2.5 times faster and web apps are now twice as responsive You will need to do a browser reboot after updating to get the ARM64 version instead of the Rosetta version[1] [1] https://supp…

Ever since I switched to my apple silicon Mac I've been using Safari, an unpleasant side effect being that apple seemed to spy on passwords (the browser freezes unless it remembers your password), and youTube ads

Re: Firefox 84.0

#275

Post by rascul »

bzbarsky wrote: post #268
rascul wrote: post #204

Earlier quoted context omitted.

I wonder if Mozilla overlooked this. IANA has 127.0.0.0/8 reserved for loopback, not just 127.0.0.1. https://www.iana.org/assignments/iana-ipv4-special-registry/...

What Mozilla is implementing here, I suspect, is RFC 6761 section 6.3 item 3, which says: Name resolution APIs and libraries SHOULD recognize localhost names as special and SHOULD always return the IP loopback address for address queries and negative responses for all other query types. Name resolution APIs SHOULD NOT send queries for localhost names to their configured caching DNS server(s). A few notes: 1) The use…

> There's really no way to win here. In theory Firefox could do the resolution as normal and then if it doesn't come back as loopback replace it with 127.0.0.1. That would be perfectly within the letter of the RFC, since noneo f the stuff above it MUST-level requirements, but probably not really within its spirit, since it would violate the "SHOULD NOT" bit.

Could a check to see if the name is "localhost" or "*.localhost" suffice to satisfy the "SHOULD NOT" requirement?

From the bugzilla comment:

> It seems reasonable to extend that to support any /etc/hosts assertions that fall into 127.0.0.0/8, but that's not something we've heard a whole lot of interest in, though there have certainly been one-off requests.

That does seem reasonable to me, and it covers more than just "localhost" names.

I do understand that most uses probably do not require resolution of localhost names to other than 127.0.0.1. I may also be a little annoyed that I'll have to make some changes to something I've been doing for a long time.

Thank you for your research and your replies.

Re: Firefox 84.0

#276

Post by Dylan16807 »

bzbarsky wrote: post #268
rascul wrote: post #204

Earlier quoted context omitted.

I wonder if Mozilla overlooked this. IANA has 127.0.0.0/8 reserved for loopback, not just 127.0.0.1. https://www.iana.org/assignments/iana-ipv4-special-registry/...

What Mozilla is implementing here, I suspect, is RFC 6761 section 6.3 item 3, which says: Name resolution APIs and libraries SHOULD recognize localhost names as special and SHOULD always return the IP loopback address for address queries and negative responses for all other query types. Name resolution APIs SHOULD NOT send queries for localhost names to their configured caching DNS server(s). A few notes: 1) The use…

My reading is that the API Firefox calls into is responsible for not pinging the DNS server.

Re: Firefox 84.0

#277

Post by dragonwriter »

bzbarsky wrote: post #268
rascul wrote: post #204

Earlier quoted context omitted.

I wonder if Mozilla overlooked this. IANA has 127.0.0.0/8 reserved for loopback, not just 127.0.0.1. https://www.iana.org/assignments/iana-ipv4-special-registry/...

What Mozilla is implementing here, I suspect, is RFC 6761 section 6.3 item 3, which says: Name resolution APIs and libraries SHOULD recognize localhost names as special and SHOULD always return the IP loopback address for address queries and negative responses for all other query types. Name resolution APIs SHOULD NOT send queries for localhost names to their configured caching DNS server(s). A few notes: 1) The use…

> There's really no way to win here.

Sure there is. Consulting the local hosts file isn't contacting the configured caching DNS server, so there is no SHOULD or SHOULD NOT violated by consulting hosts and then defaulting 127.0.0.1 if a more specific address in the loopback address range is not provided.

(Relying on a system-level name resolution API also isn't contacting the caching DNS server, and if that API behaves according to spec, including potentially relying on local resources loke hosts but not remote DNS servers for localhost domains, that would also work.)

Re: Firefox 84.0

#278

Post by [deleted] »

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…

[deleted]

Re: Firefox 84.0

#279

Post by duskwuff »

pbhjpbhj wrote: post #247
input_sh wrote: post #83

Earlier quoted context omitted.

> Major browsers can't ditch Flash until Adobe EOLs it. Adobe announced EOL a long time ago. January 12th is the day it will stop working, regardless of browser support.

A website my kids school use for maths advises it will stop worrying except for with Google Chrome, so I assume Google is keeping their flash implementation, and so flash will keep working.

That web site is wrong. The Flash player in Chrome will stop working on January 1st, and it will be removed from the browser entirely in an update early next year.

https://www.chromium.org/flash-roadmap

https://www.adobe.com/products/flashplayer/end-of-life.html

Re: Firefox 84.0

#280

Post by bzbarsky »

rascul wrote: post #275
bzbarsky wrote: post #268

Earlier quoted context omitted.

What Mozilla is implementing here, I suspect, is RFC 6761 section 6.3 item 3, which says: Name resolution APIs and libraries SHOULD recognize localhost names as special and SHOULD always return the IP loopback address for address queries and negative responses for all other query types. Name resolution APIs SHOULD NOT send queries for localhost names to their configured caching DNS server(s). A few notes: 1) The use…

> There's really no way to win here. In theory Firefox could do the resolution as normal and then if it doesn't come back as loopback replace it with 127.0.0.1. That would be perfectly within the letter of the RFC, since noneo f the stuff above it MUST-level requirements, but probably not really within its spirit, since it would violate the "SHOULD NOT" bit. Could a check to see if the name is "localhost" or "*.local…

> Could a check to see if the name is "localhost" or "*.localhost" suffice to satisfy the "SHOULD NOT" requirement?

To satisfy that requirement you have to check for those names and if that's what the name is _not_ ask the "configured caching DNS server". Which means you need to do what? Calling OS APIs will do that DNS server thing unless the name is in /etc/hosts. You could manually parse /etc/hosts and see whether it's there, I guess... That's basically Mike West's suggestion.

The parsing of /etc/hosts would presumably have to exactly match the parsing that the system DNS code does, including error recovery behavior, etc. Otherwise you might treat as localhost something that is not mapped to localhost in /etc/hosts or vice versa. This is all doable, but it's not something I'd want to do if I were tasked with this decision, absent strong indicators that this work and the extra maintenance burden and attack surface (every parser ever is attack surface) is really worth it.

Post reply on HN