Firefox 84.0
mozilla.org
mozilla.org
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 will not be treated as mixed content (bug 1220810, bug 1488740)."
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.
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.
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.
Maybe these services were coded assuming that an URL can only be 1 kb long? What if you overrun that buffer?
For example did you know that cups runs a web server at http://localhost:631 ?
TLDR: not a fan of this.
A typical Linux installation can run much more web servers on localhost. I run transmission-daemon, syncthing, cups, sometimes pagico (which is a desktop app which runs a php/web server backend on loopback).
I guess that Firefox folks have thought of this otherwise, it'd be patched pretty quickly.
There's caveats and of course servers can be configured insecurely, but this isn't a general risk by default.
> The Cross-Origin Resource Sharing standard works by adding new HTTP headers that let servers describe which origins are permitted to read that information from a web browser. Additionally, for HTTP request methods that can cause side-effects on server data (in particular, HTTP methods other than GET, or POST with certain MIME types), the specification mandates that browsers "preflight" the request, soliciting supported methods from the server with the HTTP OPTIONS request method, and then, upon "approval" from the server, sending the actual request. Servers can also inform clients whether "credentials" (such as Cookies and HTTP Authentication) should be sent with requests.[2]
* 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 requests from pages were already allowed, CORS notwithstanding, it was just not possible from HTTPS sites as it was mixed content.
* This is a pretty common pattern for lots of popular software that has a desktop component - e.g. Spotify, Zoom - so there's a clear use case for it.
* There's ongoing work to restrict this further, see https://web.dev/cors-rfc1918-feedback/, proposed by the Chrome team. In short, HTTPS will be required, and a new `Access-Control-Request-Private-Network: true` header will be sent (and an `Access-Control-Allow-Private-Network: true` response required) to force servers to opt in to any requests that cross from public origins to private ones.
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).That's simply not true, it can effect things that aren't even web servers at all: https://en.wikipedia.org/wiki/Inter-protocol_exploitation
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 done by binding to a port locally, and exposing a webserver which receives an authentication token.
Duo Network Gateway[1] authenticates this way, and I'm sure others do as well. I know Palo Alto GlobalProtect, AWS CLI, and others offer web-based authentication now, but don't know specifics of their implementation. (I work at Duo.)
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.
When the request is made to the server, the port that is temporarily bound is also sent with the request. This tells the server what URL they should POST back to. The port is random for each authentication.
> 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.
FWIW, no Javascript necessary. Just a regular POST form & Location headers. In any case, you're right - you could open up a separate connection to the server with a correlation ID, and include the same correlation ID in the initial request to the authentication server, and then upgrade the connection's permissions after the fact. You ought to be careful of session fixation attacks here. (Attacker can send Victim a link, and when Victim authenticates, Attacker is logged in. With a local web server receiving the token, when Victim authenticates, they see an error instead.)
As always, there's engineering tradeoffs in building different solutions. Some factors (besides concerns around session fixation) that may come into play:
- Typically, the authentication and authorization step occurs prior to opening a tunnel or long-lived connection. Shifting when this occurs can have unexpected or unwanted side effects. In the case of the DNG, which protects web applications in addition to SSH servers, authentication is typically provided via cookies, and so the tunnel opened for SSH is actually a sort of Websocket connection. With the approach I have described, authentication occurs prior to upgrading the HTTP request into a Websocket, in the same manner it does for web applications. In the approach you suggest, this would have to flip a bit, meaning re-implementing authentication inside the Websocket connection itself.
- What if the authentication server is not the service provider? For example, in the SAML ECP profile, the client negotiates an authentication token from the authentication server on behalf of the service provider. It then takes this token back to the service provider for cryptographic verification. You could instead teach the authentication server how to talk to the service provider directly (e.g. the HTTP-Artifact protocol) - but this works better if you own both the IdP and the SP. In many cases, customers may bring their own identity provider (e.g. Okta) with them to the service provider (e.g. GlobalProtect.)
Furthermore, browsers even having this ability facilitates inter-protocol exploitation. It's not only local webservers that are put at risk by this, other sorts of local servers can be attacked as well. See CVE-2016-8606 for an example of a browser being used to attack a guile repl.
It means you can now safely use localhost, but you could achieve the same before by using 127.0.0.1.
In the new setup proxies can't proxy localhost unless you set a pref to explicitly let them do that, and for "localhost" and hostnames ending in ".localhost" Firefox won't even ask the DNS stack for the IP, assuming loopback instead.
Which loopback, 127.0.0.1, ::1, or both?
The "is secure context" state applies to 127.0.0.0/8 (again ignoring IPv6). See NetAddr::IsLoopBackAddressWithoutIPv6Mapping in https://searchfox.org/mozilla-central/source/netwerk/dns/DNS...
I'm pretty sure all of this is clearly specified at this point, so browsers should end up all aligning on a common behavior here at some point, if they haven't yet.
1) If IPv6 disabled in prefs or caller explicitly requested IPv4 only, 127.0.0.1.
2) If localhost explicitly listed in the IPv4-only domains list in prefs, 127.0.0.1.
3) If caller explicitly requested IPv6 only, ::1.
4) Otherwise both 127.0.0.1 and ::1.
See nsHostResolver::InitLoopbackRecord in https://searchfox.org/mozilla-central/source/netwerk/dns/nsH... and nsDNSService::GetAFForLookup in https://searchfox.org/mozilla-central/source/netwerk/dns/nsD... for the key.af calculation that goes into that, as far as I can tell.
That would simplify my life when developing stuff on localhost and importing them between different things over http(s).
edit: Kids, you see those articles that regularly hit the frontpage about work/life balance ? The ones about how you need healthy sleep patterns and crunching all night long is actually bad for you brain ? This comment is what happens when you read those but don't actually follow through with recommendations.
Sorry everyone ^^.
127.0.1.12 dev.localhosthttps://www.iana.org/assignments/iana-ipv4-special-registry/...
http://foo.localhost/ -> 127.0.0.1:80
http://bar.localhost/ -> 127.0.0.2:80
This way you can have multiple services running on the default ports. 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 of "the IP loopback address" is a bit weird in IPv4, of course.
2) It's hard to know which loopback address to return from an API without violating the "SHOULD NOT" part of this item.
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 none of the stuff above it MUST-level requirements, but probably not really within its spirit, since it would violate the "SHOULD NOT" bit.
Note that Firefox is not alone here; Chrome has the same behavior last I checked. https://bugzilla.mozilla.org/show_bug.cgi?id=1220810#c28 is a comment from one of the networking/security folks at Chrome about this precise issue, in case it's of interest.
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.
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.
Calling the OS APIs isn't calling a DNS server.
If the OS API calls a DNS server, that's not really the higher-level API’s problem. If you've decided to override OS APIs and do your own ground up implementation, then you basically need to do everything an OS-level API would do if it was behaving correctly. So you either need to parse all the appropriate system files (hosts, nsswitch.conf, etc.) with the appropriate special handling of localhost domains, or have your own equivalent, app specific configuration.
The “what are you supposed to do?” complaint seems to be complaining that replacing the core OS-level name resolution facility to avoid the possibility that it doesn't comply with one spec recommendation while avoiding loss of other desirable features involves quite bit of complexity. Which, yeah, it does. The whole reason to have OS level services like that is to prevent every app that does networking from having to reimplement basic services.
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.)
Sure, see my comment at https://news.ycombinator.com/item?id=25439154
> and if that API behaves according to spec, including potentially relying on local resources loke hosts but not remote DNS servers for localhost domains
But does it?
That's dangerous. I don't want stuff loaded from localhost to have any different security context than stuff not loaded from localhost.
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?
Mozilla also don't have the brand power to push their browser to people who don't actually care but just want the notification on google.com or youtube to go away, or had it bundled with flash player or their windows install or their AV program like a lot of Chrome's rise.
My hope is it bottoms out and finds a new stable equilibrium at brave/vivaldi levels. The question is if that's a large enough position to actually maintain a browser engine.
Still more than what's available on Chrome and Safari on mobile, so it always remained my browser of choice on a phone.
Also isn't there more telemetry on by default in nightly?
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?
I'm really waiting for this
Mozilla still does not allow non-store extensions on their new firefox. Until they're back I have to keep old Firefox around. ...which sucks.
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.
It's compatible with many add-ons missing from FF on Android and has some additional features that were "lost" in the Fenix release.
Safari and Edge are defaults on iOS, MacOS, and Windows, and Chrome is the default on Android. I imagine we're primarily seeing the effects platform capture everywhere else.
https://www.businessinsider.com/google-apple-search-deal-doj...
So I would be concerned.. they're actively bleeding users... not just being outpaced in a growing market.
https://techcrunch.com/2018/08/28/mozilla-publishes-its-fire...
I'd love to give towards Firefox but have no desire to fund Mozilla mismanagement.
* Use Firefox; * Consider Pocket Premium; * Subscribe to Mozilla VPN.
If so I'm probably in (even if I don't use Pocket :-)
Firefox VPN isn't available for me yet.
I am willing to donate to Mozilla in spite of their mismanagement given that we are creeping ever closer to another browser monopoly. Ignoring bad financial decisions, Firefox is a good product and I've been using it exclusively on PC since Quantum came out. I feel that people here hold Mozilla to some impossibly high standards and turn it into outrage porn. I mean, I don't see top-ranked comments on HN about threatening to stop using Chrome because of whatever sleazy thing Google did last.
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 $100m/year and they have way more users and push really hard.
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 hedge level, not enough to shoot for dominance again. Think of it like Valve's Steam on Linux efforts -- it's not a major effort on their part, it's just enough to keep Microsoft honest.
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.
It predates KHTML/Webkit by several years so some additional legacy baggage is to be expected.
I see the main asset of firefox as being
a) not google tech
b) mobile browser with ublock
c) tech nerds with tons of custom FF addons, never wanting to switch
So I don't see them go away anytime soon, but I also see nothing to stop the decrease of their marketshare. That means, unless mozilla would focus on their core values again. They lost much trust with quite some shady actions now, over the years.
Imagine what kind of HN thread pops up if Firefox is abandoned by Mozilla.
Also Firefox is a single licensed product that is MPL, and for anyone who wants it that way commercially may support it.
It is not true at all. After a long time Microsoft's browser share in increasing. They probably are quite happy about it,.
Having more instrumentation over the platform they're doing it on is probably reasonable and realistically blink is already on every platform with over 1% usage share so that's a much easier road than supporting Trident, EdgeHTML or Chakra - the engine is not their core product - it's the stuff built on top of it.
I've used edge on linux - other than the weird thrill of seeing software that says "Copyright Microsoft" running on linux it's just a typical functional webbrowser -- that's exactly what they need.
Vivaldi is a configuration juggernaut in my experience. Reminds me of the glory days of Opera.
It has a wonderful vertical tab bar too - built-in.
- Brave: it has been pushing opt-in-by-default ads and crypto widgets
- Vivaldi: 5% closed source
- Edge: not open source (yet?)
- Chromium: lacks too many features
you can't contribute to it like you can with something on github, but the source is open none the less
browser ux really seems like 'one step forward, two backward' over the last two decades.
Realistic isn't a word I see often on HN.
It wont die. Google will keep funding it just to say they dont have a monopoly in browser market. But it will continue its path towards irrelevant by mainstream usage. They will continue to shrink the engineering as budgets are cut. Until no more silly 20% project and management goals that drains resources ( they wont have that luxury anymore ).
And someday Firefox will require a reboot, not its code base but from a management perspective.
From a user point view, Firefox will stay pretty much the same for another 5 - 6 years at least. Both the Browsers and its Cooperation. There are still quite few improvement coming from Rust Servo in the pipeline. So technically it should be competitive enough.
- From someone who has been watching / following Firefox since before its birth.
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
It works on both Xorg and Wayland.
But TBH, the last few releases from 79 showed some bugs and regressions that affected my user experience. From 79 to 81-82, I had to disable vaapi support otherwise it made video playing stutter.
And in 83, webrender caused some extensions popup Windows to be blank.
I hope Linux Wayland user experience will stabilize. But I switched to Firefox full time on my home laptop thanks to hw acceleration support and also tab containers.
It's the pie that is expanding (especially on mobile, where Firefox has hard time competing).
My fresh computer works fine.
And I'm currently using the Android app. It's buggy, but it could be Facebook or the Google keyboard. Chrome has different problems. Duck duck go has been my newest install. I still need to transfer over.
(I keep a Firefox Developer edition which I use for reading documentation, news etc. It is fully stashed up with all my favorite extensions except Bitwarden.
My main browser is almost bare bones, just BitWarden, uBlock origin etc.
As for why: I'm conservative in more than one way. The more separation I can add between customer data and auto updating extensions the better.
> 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://support.mozilla.org/en-US/kb/upgrading-new-version-f...
I often find pages render as blank pages until I refresh, and scrolling will often hang for multiple seconds. I was playing "Jackbox Games" (which is played via the web and PC), and I found those of us on Firefox found the text boxes were broken. Just downloading PDFs was broken for several weeks, and the official advice was to switch to the beta version of Firefox for Android.
DDG using Webview with built in ad-blocker seems to be the fastest android web browser I've ever used. I wonder whether it uses Chrome's data compression.
But FF Android supports extensions, at least most used ones and I hope with support for more extensions its adoption could grow.
I also only run two: Dark Reader, and uBlock Origin. It's uBlock that I find causes rendering issues on some releases of the Android app, but I haven't seen that happen in a while.
The only thing I do find painful was the app redesign removing the feature to clear all tabs on close-swiping the app. You can clear all tabs by selecting 'Quit' from the menu, but it's a hassle. I wish we could drop the forced tab persistence when closing the app as a setting, like used to be the case.
uBO just does what the filters in the filter lists dictate, so when you see specific websites broken as a result of uBO enforcing filters, best is to report these cases to the list maintainers so that this can be fixed for all.
Mozilla is invested in Firefox on Android for the long haul. We landed a complete re-architecture this year (Fenix). It hasn't been completely painless -- for example, as you seem to have experienced, we've had to split our development time between working on the new engine and maintaining the old -- but Fenix is already better than Fennec in most ways and is significantly easier to improve moving forward.
https://blog.mozilla.org/futurereleases/2020/01/17/a-brand-n...
I've been trying to find an authoritative source to signal when Android FF will support extensions (that previously worked but no longer do) -- any tips much appreciated.
I wouldn't describe that as "support" quite yet, but it's worth giving a shot to see if it works for you.
This is just sad. There was a time when I was happy to read about a new FF version for the desktop. Now I'm just waiting that they will ruin it like they did with the mobile version.
I do also see the blank screen rendering from time to time. However, I have encountered similar things on chrome as well, typically a refresh fixes it. There are some webpages that really don't seem to want to render on FF mobile though (not sure if because of UBO or something else), that's the only time I switch to chrome.
This turned out to be a surprisingly big deal to me. Every time I have to use Chrome for some reason I am bothered by how out of the way the location bar is. I think some other browsers have tried to put it at the bottom, but none that are as popular as Firefox or Chrome.
But they're not actually the bookmarks are they? They're pinned sites which are different in the browser versus desktop. And they're not collections. There are too many "bookmark things"
> Will switching to a different browser allow me to use Flash?
>No. Adobe and other browsers will also end support Flash at the end of 2020. Even if you install an older version of Firefox, the Flash plugin itself will stop loading Flash content after January 12, 2021. See Adobe’s Flash Player End of Life information page for more details
Adobe:
> Since Adobe will no longer be supporting Flash Player after December 31, 2020 and Adobe will block Flash content from running in Flash Player beginning January 12, 2021, Adobe strongly recommends all users immediately uninstall Flash Player to help protect their systems.
Am I only one who finds this disturbing?
Why do you find it disturbing?
The death of Flash isn't news. If enterprises haven't reacted to that, frankly, they never will short of killing it as is being done here. Letting is linger on just ensures it's a source of ongoing security breaches, and I think we've all seen how dangerous those can be (thanks Experian!)
That being said, there's always Ruffle:
Hell, this is precisely what Gatekeeper does on macos, in that it reaches out to the cloud to decide if you should be allowed to run software on your machine.
It's even justified on the same basis: enhancing security.
Flash games and animations were a treat of the early/mid-2000s web, and many folks got their start as creators there. Adobe hasn't just stopped distributing a player/plugin for Flash content, they're blocking the existing players from playing existing content. Even if you were an archivist there's nothing to do.
So yeah, this is disturbing. I can go to my city's library and browse microfiche if I want. I can install a Gopher or a Usenet client and connect to those widely-unused protocols that still serve content. But Adobe's reaching back and making all Flash content completely unplayable, even with players that should support it.
Wow.
Although in practice it is still hard for independent parties to implement support for all relevant open web standards, at least they are open and already have existing independent implementations.
What exactly does this mean?
Will the Flash Player projector still work after that date?
I still have some old files in my Flash archive that I would like to play occasionally, so I really hope that the projector does not have some kind of time bomb.
I'm on Nightly so I should have it for some time already, but I'm not sure if it is on by default or should I tweak some value.
layers.omtp.enabled
layers.acceleration.force-enabled
Previously I could watch even FHD videos without much fan noise, but after recent updates, fans spin at the max speed by playing even 480p quality vids. Anyone else?
I'm also experiencing FAN noise raise on my Ryzen APU based laptop.
hardware decoding, no ads, buffering as i please
https://bugs.chromium.org/p/chromium/issues/detail?id=114367...
This particular example is only slow on Chrome. Even if you move the edge of the shape into the viewport Firefox is much faster than Chrome. But I know from real life examples that Firefox becomes slow if handling large SVGs. I will have to investigate this and file a bug report.
It's very very very simple and quick, there is a video demo and a text explaining what to do, and then you can open a bug at https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&comp..., with the profile link (you can login with a github account or email). This will be triaged and hopefully we'll understand what's up. Please use a Nightly build or a Mozilla-provided build when doing so (so there are symbols). It's just a matter of downloading and untaring the tarball.
Please also attach a copy of `about:support` raw data (button at the top), so we can understand what your configuration is: desktop Linux systems can be pretty diverse and sometimes it isn't clear what works, what doesn't and why.
If you're playing 480p, then youtube might be serving you AV1, and this is (for now) using the CPU (trading a lot less bandwidth for increased CPU usage), you can check the codec it's using by right clicking on the video and clicking on `Stats for nerds`, there is the codec string. You can adjust your codec preferences in your youtube profile I believe.
Not sure if it's this update or the last, but the added the ability to show the bookmark bar ONLY on the new tab screen ala Chrome's behavior. I can't stand bookmarks as a side panel like the old FF behavior, and not a fan of tree style tabs. Having my bookmark folders on the new screen has been great.
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.
Clearly Ruffle is not perfect, but leagues, furlongs ahead of having to watch old flash content on YouTube via Unregistered Hypercam 2.
In fact it ran perfectly.
From these panels, you can pretty much do anything you want to the physical server - Open a console session, change boot order, bios, etc.
Screenshot: https://imgur.com/iWYJIpU
Adobe announced EOL a long time ago. January 12th is the day it will stop working, regardless of browser support.
https://services.harman.com/partners/adobe
Adobe, Mozilla, Google, Microsoft, and Apple simultaneously announced back in 2017 that Flash would no longer be supported after 2020:
https://developer.mozilla.org/en-US/docs/Plugins/Roadmap#See...
Finally, now I can use Firefox again. I have an older box, about 10-years old :-) I see noticable speed improvement on linux. I only use few extensions with dark theme, like uBlock/uMatrix/Dark-Reader. I've been using "Ungoogled-Chromium" for the past few years. Its nice to see Firefox improving things on linux. Will definantly use it more now.
I've been using FF since Netscape, and it used to be a few settings and we're off. Now, you have to edit policies.json to get updates stopped, autoconfig.js and firefox.cfg to disable telemetry, legacyUserProfileCustomizations to use userChrome.css to get anything like a proper menu system.
'Lockwise' has dumbed down the login system so much you can't even change field names, making many sites incompatible. Nor can you import logins from file or even point to installations to import. The add-ons system is like traveling back in time ten years, bugs and fewer alternatives than ever, still can't figure out how to stop Tree Style Tabs from stealing mouse focus from the page onmouseover like a widget. -And these are problems that were fixed before they were reinvented.
For the first time in 16 years I'm seriously trying alternatives.
-these were my views on 83, i hope to hell 84 fixes some of them.
You can change this in the configuration dialog, and once disabled, that setting will be preserved through Firefox upgrades. You shouldn't need to change this repeatedly.
> legacyUserProfileCustomizations to use userChrome.css to get anything like a proper menu system.
By "proper menu system", do you mean having the menu bar always visible? You can enable that with View->Toolbars->Menu Bar.
> you have to edit policies.json to get updates stopped
Doing so would result in running an outdated and potentially insecure browser.
The options in config were greyed out in 83.
> "proper menu system", do you mean..
The ability to make multi tier menu with icons or text instead of both
>Doing so would result in running an outdated
Doing so would result in a stable system that wouldn't just randomly disable all addons from working, security related addons at that.
I'm running Firefox 83, and those options are still available. It's critically important that Firefox support disabling telemetry.
If you've edited those options via one of the lower-level preference systems, such as autoconfig.js, you may have locked them, which would cause them to show up as greyed out.
You need to create the file firefox.cfg in install Dir and enter lockPref("toolkit.telemetry.enabled", false); To override it And to get that to work you need to create /defaults/pref/autoconfig.js with pref("general.config.obscure_value", 0); and pref("general.config.filename", "firefox.cfg.js");
Its getting harder and harder to make a good browser out of FF, I personally don't mind the work, but things like Lockwise replacing a working password manager without the needed options and no addons to fix it or workarounds, i can see it messing up fields in PasswordFox but can no longer do anything about it.
No thanks.
MS pulled that shit.
It's _my_ computer. That's a principal reason I installed Phoenix in the first place.
I don't auto-update because people running projects do what for me are stupid things like break all the add-ons, knock holes through my adblocking, remove key settings, add non-removable addons, etc., etc., and they do it without warning or option.
Not to mention the UI changes which annoy and confuse elders that I support.
I don't have time for supporting forced beta testers (family & friends, I'm a home user) so auto-update stays off for projects that think it's their device one is using.
However I'm very disappointed with the corporate way it is managed. Lot's of money for the CEO and cutting development funds.
Things I would absolutely buy from Mozilla: private internet services
- Something like Zoho: Calendar/Mail/Notes replacement for Google services!
- VPN server if available in my country
I want to ditch google/apple/microsoft for something "encrypted/private" first. And self-hosting is just a hassle. Provide me easy, "self-hosted"-like services please.
I run Firefox Nightly on my work mac (with Cylance) and have been seeing this. Luckily IT have happily whitelisted it and reported back to Cylance, but still slightly weird that a major application would be flagged like this.
That said, once you figure out its weak spots, it's as useless as all the others, but it doesn't surprise me it'd flag Firefox.
https://addons.mozilla.org/firefox/addon/to-google-translate...
Chrome was just easier to deal with.
Could someone share:
- is there any progress on fixing the extensions API (it doesn't have to be exactly equal to the old, but for example some way to disable tabs on top would be highly appreciated as I always use Sidebery or TST in one or more browsers.) (I generally don't complain much about ux/ui, but this is a real mess).
- Are management aware that many of us badly wanted to support the Firefox / Servo teams while we just as badly don't want to support the people who fired lots of them, agreed to shady extension deals etc? (Personally I would accept a heartfelt apology and a change in direction.)
Out of the three, only Pocket is widely available. FPN is US-only, VPN is only available in like 5-6 countries.
Anyone know any more details about this one?
> .. it should avoid the problems we'd been seeing with overly small /dev/shm in container environments (which were causing serious problems for using Firefox for automated testing of frontend projects).
docker has a 64M default for /dev/shm that can be overridden, but in hosted CIs it is not always accessible. Chrome is a user of the IPC shared memory too and trips over it in pipelines because of the low default. They track memfd_create at https://bugs.chromium.org/p/chromium/issues/detail?id=798221
[1] https://www.mozilla.org/en-US/firefox/android/84.0/releaseno...
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...
My newgrounds nostalgia hit me hard after reading this. Despite any criticism on flash it self, there were some pretty cool stuff made with it all the same.
http://blog.archive.org/2020/11/19/flash-animations-live-for...
Bugs from a quick play-around (comparing with Microsoft Edge):
* The zoom with touch pad has a weird latency not present in Edge.
* Zoom on touchscreen is janky and jumps around.
* Zooming in and then out often (but not consistently) stops working half way through the gesture.
* Scrolling behaviour while zoomed is wildly different to native apps like Edge. Scrolling is extremely fast and has some kind of acceleration.
* Pinching while scrolling on the touchscreen lags badly.
It just feels shitty. Firefox devs don't care about a polished experience on Windows touchscreen laptops and it's a dealbreaker for me.
Maybe check your touchpad and touchscreen drivers.
I haven't been using Firefox for nearly 20 years because of a rendering engine, I've used it because of its features. In the last 20 years, most people have moved from desktops to laptops and phones, native app battery use and performance means a lot more than features.
As a last ditch attempt you could try https://addons.mozilla.org/en-GB/firefox/addon/multi-touch-z...
But if that doesn't work it may hint that pinch gestures aren't being passed to firefox properly; try pinch zooming on maps.google.com, if that doesn't work then maybe there's a deeper issue going on
If it's janky it might "just" be a performance issue. If you could grab a profile from profiler.firefox.com that would be much appreciated
Previously a search for an empty string would go to the quick search link with an empty query. The previous release wouldn’t let you submit the search without a non-white space query. Which breaks using the quick searches as bookmarks.
It might be due to my combination of browser settings and add-ons, but I've found the Firefox developer console to be less than perfectly stable.
Does WebRender imply major speed up?
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 a common thing I'm surprised it hasn't been fixed.
It's certainly worth filing a bug over. https://bugzilla.mozilla.org/enter_bug.cgi
I actually just tried again, and Netflix does not seem to be doing it.. only Hulu. It does this on multiple machines so perhaps just Hulu <> Firefox specific.
https://www.zdnet.com/article/former-mozilla-exec-google-has...
We have five Windows 10 computers - 3 Intel laptops, 2 with nVidia graphics. 1 Ryzen laptop with nVidia graphics. 1 Ryzen desktop with Radeon graphics. None of them have the tearing issue when watching videos on YouTube using Firefox.
The Ryzen laptop and desktop have 144hz screens. The rest are 60hz.