Firefox 68.0
mozilla.org
mozilla.org
The new remake of the mobile browser ("Fenix") does not have extensions support and it is on an indefinite and easily ignorable backlog. It is explicitly not being worked on this quarter. At the end of this quarter is the scheduled release of Firefox 69. Unless there's no release at all of Firefox 69 upon the Android platform, that's the time when Mozilla I think will deceptively try to drop support for extensions/addons on android.
Bug to have Add-ons pages declare Fenix extensions as unsupported. "version <= 68.0.98 is legacy Fennec version >= 68.0.99 is Fenix (or some other GeckoView-powered browser)" https://bugzilla.mozilla.org/show_bug.cgi?id=1548428
"Or do nothing because Fennec 68 and Fenix 68 will overlap for only 6–8 weeks with a preview audience." https://github.com/mozilla/addons-frontend/issues/7963
Firefox 69 releases 2019-09-03 at the end of Quarter 3. https://wiki.mozilla.org/Release_Management/Calendar
Extensions support are in the "Reserved Backlog" category. Also locked to prevent any more comments about it. https://github.com/mozilla-mobile/fenix/issues/574
Extensions support is not in Q3 backlog https://github.com/mozilla-mobile/fenix/projects/19
To me it's even the single biggest reason to use Android over iOS as there's no full featured browser on iOS.
>No. The browser is not fully open source like open in open source. It is a common myth and misconception about Kiwi Browser.
>Damn, 1 commit and nothing else but keeps updating and releasing apks? Looked into the issues and scarcely seen replies.
>I think this repo is just to show that "hey, I provided the so-called source code (even though not fully open-source as said above) so trust me and install me" thing.
Kiwi was started as a fun+independent project, then more and more people asked access to some source to be able to develop their own hacks (new tab page, extensions, bottom toolbar, import/export bookmarks, AMP, etc) and they are shared when the devs ask politely.
At the end of the day, if you use Samsung, Kiwi, Fennec or Yandex, what matters is to understand why the developers are doing their project, what do they get from it (not necessarily money), and what are the influences around. The source-code is one indicator, and, unless you actually have reproducible builds (and only Fennec has them from all the mentioned browsers) you have to use your intuition.
F-droid does independent builds. Even if it's not reproducible, I trust them more than over some random developer.
Well, no. I don't want to use a browser that is developed by an advertising company, and I want to encourage the development of more than one web rendering engine. But yes, killing extensions would be a major regression in Firefox's usability.
... on an operating system developed by the exact same advertising company?
To be clear, not one of the Android devices I've purchased have ever had official support. I'm using a Samsung a8 at the moment.
I hope the custom rom community finds a better mechanism for providing better device coverage.
It's the new "Firefox Preview" that doesn't (yet).
Mozilla broke extensions on desktop Firefox before and lost many users. Can't help but wonder what the hell are their product managers thinking? How can I recommend Firefox if they keep breaking it with little regard for users?
Is there another browser that supports uBlock Origin for Android? I'm not talking about biased half baked built-in ad blockers, I want the full open source extension.
For browsers this seems like a bit too long without updates. I can imagine maintaining such project is demanding but hopefully the project can gain more attention now with the new version of Firefox breaking extensions on Android.
The browser seems to get regular enough updates on play store, has decent ad blocking (at least good enough for my purposes) and to date has the best night mode out of all android browsers I've tried.
No white flashes like I've faced in Firefox for Android. The dark mode applies to the whole of the browser UI.
I use Bromite, Firefox for Android or Fenix mostly equally during the day and Kiwi at night.
Though the fact that it is not open source may put some people off.
It's not clear what you're asking. Mozilla changed the add-on API, and the new API does not have all the features that the old API had. Two add-ons that I liked very much died during the switch.
Do you have the data for this? I know I live in a techie bubble, but it sure doesn't fit with my experience or the experiences of others I know who talk about it.
"Has Add-on" has been between 33-38% for the last two years.
[1]: https://github.com/Cookie-AutoDelete/Cookie-AutoDelete/issue...
[2]: https://www.ghacks.net/2017/12/01/noscripts-rating-drops-aft...
48 months.. 2 years of notice
This also happened a short time after Mozilla previously broke addons with the e10s changes, requiring many (most?) of them to be rewritten.
Basically, people don't trust Mozilla to handle transitions well any more, even when they happen to be worthwhile transitions.
(I'm not paid by samsung, just trying to help fellow readers)
Now they are going to kill extensions in Android FF, which will kill the only non-ideological reason my family is using it - for the adblocking extensions.
I'm guess enough ad-based companies with deep pockets finally bullied Mozilla hard enough.
Did you ever support an old SOAP server made in '90, that had a lot of bugs, that was slow as hell made of molasses, and was vulnerable to several security exploits?
Now imagine you have millions of users demanding, speed, security and those XML add-ons , I mean servers.
Basically Mozilla decided to ditching the old system in favor of the newer one, was the best choice at the time.
I wasn't saying bribery. I'm talking about bullying through other means.
So now I have to do what I do on my desktop: Chromium for casual browsing and an old non-crippled version of Firefox for getting things done. Thankfully I only buy phones I can root and block ads system-wide.
From Firefox's dropping extension support to Windows' removal of granular update controls the tech industry's inexorable slide away from user control makes me want to cry tears of impotent rage.
Do you have a source for that or are you just making things up?
My observation was that Mozilla consistently responded to complaints from extension authors by implemented new apis for their webextension implementation to allow extensions to be ported. That's pretty far away from "Go Fuck Yourselves."
> Mozilla introduced many new WebExtensions APIs in Firefox 57 [Quantum], such as the openerTabId property for tabs. The opener information is highly relevant for Tree Style Tab. [0]
[0] https://hacks.mozilla.org/2017/12/webextension-tree-style-ta...
I even have a pretty decent UserChrome.css to better integrate Tree Style Tab, https://www.reddit.com/r/FirefoxCSS/comments/ao3ydl/configur...
Switching the webextensions was necessary to continue improving browser performance. It's my perception that they tried to accommodate extension authors with new apis to allow as many extensions as possible to be ported.
What they haven't done is given a clear statement. Nothing about if their replacement is going to drop extension support. But every response from Mozilla has been a sidestep and that I cannot overlook.
That is incorrect, and stems from a misunderstanding of our release model.
> What they haven't done is given a clear statement.
The clearest statement is this dev-platform post from April, https://groups.google.com/forum/#!topic/mozilla.dev.platform..., which includes a link to a much more detailed project planning document.
> Nothing about if their replacement is going to drop extension support.
That's because we are not yet ready to make public commitments. Honest. We're building the app and its underlying embedding library (GeckoView) from scratch, and as with all new greenfield projects, we're still working on getting the foundation right. It's simply too early to forecast how that specific design and development work will play out.
So why isn't extension support considered a must-have?
>That's because we are not yet ready to make public commitments. Honest.
Surely you can understand how this isn't good enough for most addon users, right? You've already announced Firefox for Android is going to be deprecated. And you're "not ready to make public commitments" about whether the replacement is going to support extensions?? That's obviously not acceptable to addon users.
If Mozilla's policy is that they simply don't care what users think, then whatever, it doesn't matter what's acceptable to addon users. I'm writing this under the presumption that at least someone in the Mozilla org does care about this.
As Ricky would say, "It doesn't take rocket appliances."
> We're certainly aware of how significant ad blocking extensions are. This release required a great quantity of features with only a six month timeline until now.
> We already support a very limited set of the WebExtensions API to offer features like Reader Mode. Rest assured that more features will land in the coming months.
Source: https://news.ycombinator.com/item?id=20298143
This reads like FUD to me. The dev team know how important extensions are to their users.
Just because they know how important it is doesn't mean they care.
I'm sure Google also knew how important ad blocking was to many Chrome users when they decided to remove that functionality from their browser, too.
I originally commented there and expressed how they were underestimating the importance of ad blocking. One of the issues I pointed to as evidence (https://github.com/mozilla-mobile/fenix/issues/96) has since been re-prioritized to Q3.
They seem to have heard the message.
And, yes, there's the "ad blocking" issue: https://github.com/mozilla-mobile/fenix/issues/96
What does it actually say? The requirement is "Integrate/support for different adblock lists (see Focus)".
So you can have certain ad-block lists, but not the actual customization and not uBlock Origin.
What has Mozilla publicly stated about extensions and their rewrite of android firefox? I'd love to see something clear they've stated.
https://github.com/mozilla-mobile/fenix/issues/662#issuecomm...
I'm sure Fennec users will not be migrated to Fenix until extensions are supported. This would be a big fuck up and Mozilla is aware of this.
Linked bugs about the user agent seem irrelevant to this issue.
Everything will be okay. You can sleep on both ears.
They're relevant because that's what suggests that they aren't planning for a Fennec 69: addons.mozilla.org is currently interpreting version 69 to mean Fenix, so if Fennec gets updated to 69 they'll have broken extension support anyways. If Mozilla is abandoning Fennec at version 68 before Fenix is even close to having extension support, they probably can't be trusted to not push out Fenix to users prior to implementing extension support. Their messy transition to WebExtensions certainly provides precedent for Mozilla making this kind of fuck-up.
It got picked up by a handful of news outlets, but there's just a lot of news these days, so it's easy to miss things.
Plainly speaking, is it a possibility that Firefox on Android will lose extension support for some time in the future?
So the question is whether or not Fennec's replacement will support add-ons when Fennec finally hits End of Life. And I know this sucks as an answer, but we're not yet ready to make public commitments on that front. That's not because we have bad news hidden up our sleeves, it's just... we're still working and designing and figuring this stuff out.
If you want to know more about the architectural mess we got ourselves into, and how we're extricating ourselves from it, I highly recommend reading through this internal presentation on the topic: https://docs.google.com/presentation/d/1MzU9q2wCwojC0kb1eVfm...
You imply that this doesn't mean that it will not, but also not that it will. What you will say about it is that addons are hard.
Taken together, those statements don't exactly foreshadow good news.
> I can't make any specific commitment, but there's a lot of time between now and Firefox for Android going EOL (and we haven't committed to specific timing for that, either.)
> However, we do have concrete plans for supporting adblocking as a built-in feature in the near future (https://github.com/mozilla-mobile/fenix/issues/96), which should make Preview more palatable to folks who rely on add-ons for that, even if only as a stopgap.
> More fundamentally, when considering major features like add-on support, we want to take the time to ensure that we're getting our design right at all relevant levels: Firefox Preview, the underlying GeckoView library, and the Gecko engine itself. And though development on Preview moves quickly, there's still a lot of design and development work yet to be done.
My understanding is that there's a good chance that Firefox 68, which supports extensions, will reach EOL before 69+ gets support for extensions.
I agree with you however. We don't have any guarantee at this point.
Please, Mozilla: don't EOL Fennec before supporting extensions on Fenix. This would be a huge mistake. Extensions are useful beyond adblocking. Chrome not supporting extensions on mobile is not a good reason to consider that Fenix would be good enough without support of extensions. Chrome is not good enough. If Fenix is not ready early enough, please consider releasing a version 69 of Fennec and then later versions until Fenix supports extensions.
We are focusing all new feature development in Firefox Preview, but we're continuing to support Firefox for Android as an Extended Support Release while we build Preview.
And, for what it's worth, we do understand how important extensions are to folks, and we are taking that into account in our planning.
However, we do have concrete plans for supporting adblocking as a built-in feature in the near future (https://github.com/mozilla-mobile/fenix/issues/96), which should make Preview more palatable to folks who rely on add-ons for that, even if only as a stopgap.
More fundamentally, when considering major features like add-on support, we want to take the time to ensure that we're getting our design right at all relevant levels: Firefox Preview, the underlying GeckoView library, and the Gecko engine itself. And though development on Preview moves quickly, there's still a lot of design and development work yet to be done.
I also work on an open-source project, and I understand where you're coming from WRT decisions that are unpopular on the outside, but make sense when viewed from the inside. But as a user of Firefox, having already gone through one round of breaking extensions I quite liked with no apparent benefit to me as a user, I'm really not enthused about going through another round of this. Adding a built-in ad-blocker is fine, I guess, but I also use NoScript on mobile. Is that going to die when Firefox for Android goes EOL? What benefit am I going to gain by giving up another one of my core add-ons?
I know you can't answer that here and now, but please, seriously consider how this looks from the user's perspective. I love Firefox and I would like to continue to do so.
reading this almost makes me cry because that is the same bullshit google is telling us with chrome.
Firefox is not supposed to block ads! Firefox only has to provide an interface for addons so they can do whatever(!!!) they want (for example blocking ads or installing malware on your system).
Please don't sacrifice our freedom for a wrong understanding of security (like that addon-signing you pulled lately).
Having a built-in ad blocker doesn't hinder an app from also accepting extensions which block ads.
But you brought up another point: I think it is in the nature of an adblocker, that it MUST be "elitist" to be actually useful. If every browser does "adblocking" by default, the ads will just adapt. That will be as useless as the HTTP-Header "dont-track-me".
The switch to WebExtensions allowed all the excellent performance improvements we have been seeing in Firefox over the last year. So it improved the performance for everyone, and broke a feature that a small minority used. That minority is a highly specialized, highly trained, bunch.
If you think that features that benefit a small elite group of users should trump improvements for all, then I think that is an elitist attitude.
Also, here there is absolutely no talk about changing extension APIs. So I don't see why extensions that work now shouldn't continue working in FF Preview once Extension support is added. The situation is pretty unlike the WebExtension situation.
So yeah, hold their feet to the fire to make sure that things don't regress without need. But also look at what they are trying to do with merging the FF Focus stuff in, and getting a built-in adblocker. They are doubling down on privacy for all. This should be commended.
Consider the following: over the years I have convinced a dozen or two users in non-technical careers to switch to firefox. Most of them do not install extensions, at least for themselves. However, without extensions, I would not have recommended firefox to them in the first place. Firefox's rise in popularity is owed to the word of mouth campaign carried out primarily by people with technical/foss careers or inclinations. Why would I, or anybody, suggest a browser that I do not enjoy using? To suggest software to somebody is to go out on a limb for that software, because if the person you are suggesting it to has a bad experience with that software, your personal reputation will take the hit for recommending it. So why on earth would I stick my neck out to promote Firefox when Firefox is no longer software that cares about the needs of users like myself? If Firefox has adopted a "socially progressive" model of disregarding the needs of technical users because such users have more software-privilege, then they have taken the wind out of their own sails[sales].
(I put the words 'social progress' in scare-quotes because I also reject the premise that infantilizing software is in fact socially progressive. In truth it's socially regressive, since it's effectively technical people deliberately reducing the exposure non-technical users have to technical problems that might challenge them to learn more. The true impact of infantilizing consumer software is to pull the ladder up behind us. Reinforcing and widening the dichotomy between technical and non-technical users is inherently socially regressive.)
Also, the Internet and most technology happens to break existing workflows. We shouldn't assume disruption is bad if the result is an improved version.
Instead, think of Firefox for Android as a Long-Term Support (LTS) release, like you might see with projects like Ubuntu, Node, or Django.
There are no new features coming to Firefox for Android, but we will keep the 68 branch alive and maintained to ensure that everything keeps working and is secure on Android. We will do this for at least another year, to give Firefox Preview more time to develop and mature.
On desktop, we do something similar with Firefox's Extended Support Release ("ESR") versions (https://www.mozilla.org/en-US/firefox/organizations/). Every year, we pick a version of Firefox that we commit to supporting for a very long time. Last year, it was Firefox 60. So even though Firefox 68 is available, we're still backporting patches and fixing bugs in Firefox 60. This year, Firefox 68 is the ESR version, so we'll support until at least late next year.
Anyway, I use firefox on Android because of the ad blocker and to avoid AMP. If the new firefox works similarly in that regard, then I might end up switching to that instead.
I use Firefox because I enjoy the freedom it grants users do modify it as they see fit. If the play here is to turn adblocking into a walled garden feature so you can monetize it either on the user or advertiser site I might as well go back to Chrome.
[1] I mean in a fully general sense, not “oh it’ll take effect after each tab fully loads”.
This is indeed what "dead" looks like.
This sounds a bit like FUD since Firefox on Android is faster than Chrome for me. Your wording also implies it's insecure, which I don't think is a correct evaluation.
That said, I do find Mozilla's behaviour on this quite saddening.
My bad for trying to help I guess.
Otherwise it's no big deal for me, I'll just go back to Brave :-/
Without extensions you're going to lose power users, and in my opinion (as one), power users are also the biggest advocates of Firefox.
This would be a mistake.
This sounds awesome:
https://mozillagfx.wordpress.com/2019/05/21/graphics-team-sh...
> WebRender is a major rewrite of the Firefox rendering architecture using the same kind of GPU-based acceleration techniques used by games.
I really hope it gets pushed to other Operating Systems as well in the future.
Edit: Here's the link to their hacks mozilla blog post about WebRender Interestingly this piece of tech is from Servo:
https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-f...
"We currently have WebRender enabled in Nightly for:
* Recent Intel and AMD GPUs on Windows 10 desktops
* Linux users on Intel integrated GPUs with Mesa 18.2 or newer with screens smaller than 4K"
It may be worth noting that WebRender was already deployed to Win10/Nvidia users in Firefox 67.
You can enable/disable webrender in about:config if you want to try it out (gfx.webrender.all). I've switched to it on my laptop (HD Graphics 620, Gentoo Linux). So far so good.
Mozilla is just using a conservative, staged rollout to limit the impact of bugs.
gfx.webrender.enabled
gfx.webrender.all
It's not surprising they get low-priority when Apple makes it a pain to do write a crossplatform app that is supported on their platform.
Thanks for pushing the web forward!
I disagree that Chromium is evil. Personally, I use Firefox because I like it better. Though, on Android I use Brave which is based on Chromium and has ad blocking, privacy, and anti-fingerprinting built-in. Just a really quick easy way to get all of that in a simple no fuss package.
For example the recent controversy about restricting API for ad blockers will affect Chromium as well.
Making a browser that breaks extensions used by millions of people (Vimperator comes to mind) and making extension development harder is not pushing the web forward.
Reality is, most popular add ons got ported very quickly, and the subsequent speed and reliability improvements for Firefox that would not have been possible while keeping the old extensions around have more than validated their decision.
P.S. Vimperator had 15,000 users according to https://web.archive.org/web/20171016205807/https://addons.mo... Vimium-FF alone has 26,000 now.
In fact, very little has been added that has made our life easier (the main one being the search API) since we first started developing Tridactyl. Features have actually been taken away from us - notably the ability to operate on PDFs.
Not to detract from your point, though - most of the API was already there and fine in September 2017.
Speaking as an end-user, I find the eagerness with which web developers re-purpose key events to be extremely aggravating. If I hit ctrl-F, I want to use Firefox's native full page text search, not jump to the in-site search box.
I'd like to see Mozilla start treating key event capture as an opt-in-required permission like site notifications, location, camera, and microphone. Currently the only way to blanket-deny permission to capture key events is by disabling javascript. That's not ideal.
You roll your own by writing a userscript (e.g. Tampermonkey) that adds an event listener to keydown which runs key.cancelBubble = true and key.stopPropagation(). See line 343 https://github.com/tridactyl/tridactyl/blob/master/src/conte... (starts "leavegithubalone").
Two of my extensions are also participating, reviewers took special care in how user data is handled and how accurate the privacy policy is. Overall the program seems to be a positive development that will give us a curated list of safe browser extensions to use.
I used to have an extension live after it being reviewed, sent them an update a few weeks later, and they took down the old version without warning because the original reviewer didn't do something correctly (from what I can remember). I then had to wait a week before they could review the update and put it back live again by which point, a large portion of the userbase had disappeared and all our marketing efforts gone to waste for an entire week.
Never again would I deal with Mozillas reviewing processes.
What impact will this have on web development without a web server? It sounds like you won't be able to load CSS or JS.
Either way, exposing local files to an internet proxy just to open them in a browser is overkill. Lots of script runtimes come with their own lightweight HTTP servers nowadays. For example, I use Python's with "py -m http.server".
Still it's not great.
The release note refers to script access (XHR, DOM access across windows).
Script running in a page loaded from file:// will not be able to access the DOM or text of any other file:// URLs, other than the one it's running in.
That said, if they work in Chrome right now they will also work in Firefox 68.
php -S localhost:8080
As of today's upgrade opening file:///home/skx/bookmarks.html no longer loads the JS/data. Breaking the system:
https://github.com/skx/bookmarks.public
Adding a local webserver is fine, but it's a complication I'd managed to avoid.
For reference this is the error I get:
> Cross-Origin Request Blocked:
> The Same Origin Policy disallows reading the remote resource at
> file:////home/skx/bookmarks.data.
> (Reason: CORS request not http).
> New reporting feature in about:addons allows you to report security and performance issues with extensions and themes.
> Redesigned extensions dashboard in about:addons provides easy access to information about your extensions, including data and settings access required by each extension. Find high quality, secure extensions via the Recommended Extensions program in about:addons, which now displays user count and ratings for each extension.
> "Recommended” badges for these extensions also appear on AMO. More extensions will be added over time.
I welcome the new changes to the extension ecosystem. For too long extensions were unsupervised and malicious code was allowed to run (remember the Stylish fiasco[0] where your browsing history was siphoned off?).
App stores and extension ecosystems need to be policed with a lot more rigour and code needs to be inspected so that the extension does what it says in the description and nothing more. No ulterior motives. No 'monetizing' of user data, and no surreptitious phoning home to a command and control server with your browsing history.
[0] https://www.ghacks.net/2017/01/04/major-stylish-add-on-chang...
But more than anything... BigInt! Finally! JavaScript has real integers on Chrome and Firefox now! (The TC39 proposal is at Stage 3: https://github.com/tc39/proposal-bigint)
/* Put the content below into your <firefox profile>/chrome/userChrome.css */ .browserContainer { background-color: #000000 !important; }
(More broadly, I wish Apple would allow things like file dialogs to force to dark mode. I know you can set NSRequiresAquaSystemAppearance to NO, but it tends to mess up a bunch of other random stuff too)
1) Videostreams are way smoother using Chrome, at least on Linux.
2) I've enabled Emacs Input in Gnome. When I enter something in the address bar, both Firefox and Chrome show suggestions for websites below. In Chrome I can type Ctrl+n / Ctrl+p to navigate between the suggestions, because it respects my keyboard schema.
In Firefox this opens new browser windows :( and I've found absolutely no way to change this behaviour.
But using gnome tweaks you can enable Emacs Input, which if you are used to emacs key bindings, is really handy navigating in gnome-terminal or, as mentioned web browser address bars.
This is also the reason I use Chromium. I'd switch to Firefox as soon as it supports VA-API on GNU/Linux.
2) I'm also confused about the state of Gecko Embedding. As far as I know many are jumping to Chromium instead of Gecko. What's the plan there? Is Chromium better/easier to embed? Will I be able to embed Servo at some point?
What was planned and is happening is that a lot of the exploratory work happening on Servo is being integrated into Firefox in parallel. WebRender is one example of this work: it's (effectively) a Servo component that is now in Firefox.
Another example of the above is Stylo/QuantumCSS, Servo's CSS component. This post on Stylo/QuantumCSS gives a good early insight into the overall project to bring these components to Firefox https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en...
> many are jumping to Chromium instead of Gecko. What's the plan there? Is Chromium better/easier to embed? Will I be able to embed Servo at some point?
- Chromium is much easier to embed than Gecko
- Servo can be embedded now (and uses the same/a similar system to Chromium), but as mentioned above, Servo as a whole isn't stable.
- Making Gecko/Firefox easy to embed would be great, but at this stage I think this is largely a matter of focus, resources, priorities.
- On a related note, there is the GeckoView[0] which is a project to build an easily-embeddable Firefox for Android
Instead of opening a new window with the requested profile, it opens a new window of the same profile that's already running.
Launching from about:profiles works.
Is anyone else running into this?
Now I regret chrome almost not at all.
Thanks for the hard work to all involved.
Or maybe it's a different rendering library / os / gpu driver interaction.
my first reaction is it's really sad to see this. looks like something Google blackmailed them into adding. maybe Im missing some aspect to this.. but why is mining crypto bad but showing ads is not?
I rather mine coins/ether/whatever for the website owners than see more ads
moving away from the web being funded by advertisement to a web funded by distributed computing is what a lot of people have been looking forward to, no?
As such, they’re a favoured tool of script-kiddies who deface websites. They take over a site, and then drop a crypto-miner onto the site to make themselves money, otherwise leaving everything intact. Sometimes even the site owner doesn’t notice anything has changed for quite a while. Meanwhile, an unaffiliated third party is now making money off of their website on the backs of their users.
This is being used by anybody who can sneak a javaascipt into your page or an iFrame that you embed, which has become too easy to do. When it comes down to it, IMO, site owners are responsible for what ads and scripts they allow to be served via their page, but I think I'm in the minority on that opinion.
Ad networks (the more reputable ones anyway) are playing a cat and mouse game of allowing a Turing complete js environment and trying to prevent its use for doing particular pieces of math. I'm glad Firefox is joining in as well, but I'd be happier if we didn't have this problem to begin with.
There seems to be a conflict of interest when a browser singles out one of the biggest threats to the online ad industry while being funded by that same industry
(~90% of Mozilla's money is from Google according to Wikipedia)
While we're on the topic, does anyone have a good guide for adding a crypto miner to a simple static website? (like Githubpages)
about:performance aims to do that.
Edit: alternatively, you can enable this per-site by clicking the shield icon that appears next to the URL when something has been blocked.
Edit: to clarify, I would have answered your question if I knew. I don't, but I think those sites give good answers.
> Presentation attributes on any SVG namespaced element
Is Firefox going to support this?
It's already supported in Chromium and makes it nice to use the web animations api (e.g., myRect.animate) on svg elements.
[1] https://developer.mozilla.org/en-US/docs/Web/SVG/SVG_2_suppo...
How to resist that sweet money coming from ads networks ?
Mozilla: fix it.
"Please don't comment about the voting on comments. It never does any good, and it makes boring reading."