Live data from Hacker News

Firefox Android now supports Tampermonkey

support.mozilla.org

241–250 of 301 posts

Re: Firefox Android now supports Tampermonkey

#241
post #226

Earlier quoted context omitted.

F-droid Fennec has the same whitelist of available extensions as regular Firefox

Yes, but it supports the custom addon collection feature. This way you can use it in a browser that isn't based on the beta/nightly branches, and should be less crashy. I run Fennec to access a few privacy redirect extensions, largely to make reddit and twitter less awful to browse without their respective apps.

I had been using Fennec for a while and had no idea! Instructions here: https://old.reddit.com/r/fossdroid/comments/p7mgec/guide_usi... (also, collection names should not contain spaces, it seems)

Re: Firefox Android now supports Tampermonkey

#242
post #82

Earlier quoted context omitted.

It really is bizzare, old Firefox used to support all addons, then they shipped a new version and only allowed like 10 addons, and to this day they don't allow any more. It's already been years. I know my addon works fine on mobile, but they provide no means of specifying that*. I tried to email them for it to become "recommended" but never heard back. The fact that they allow tampermonkey which allows any kind of sc…

As far as I know you can install any addons you want, you just have to create your own collection. Those default addons you see are only Mozillas standard collection. Even do I would like there were more addons to choose from as default I can understand Mozillas choice here. And that is that most addons are not design for android and they would not work or give a very bad UX. So for many non tech savvy standard users…

>As far as I know you can install any addons you want, you just have to create your own collection.

I'm also very interested in bypassing the mobile limitation. Does creating a custom collection require an account? Ive never seen the option and have tried everything to back to 2019-2020 Firefox plugin capabilities.

Update: For anyone in the same position, I just saw this solution in another comment. Its unfortunate that such basic functionality requires a whole user account.

>For reference, to work around mozilla's artificial restrictions, you have to use nightly. Once you activate the debug menu (about firefox > tap logo 5 times) there's the option to set a "custom add-on collection". You can make a custom collection on addons.mozilla.org using a firefox account. The two fields are the last two parts of the URL on your custom collection.

Re: Firefox Android now supports Tampermonkey

#243
post #226

Earlier quoted context omitted.

F-droid Fennec has the same whitelist of available extensions as regular Firefox

Yes, but it supports the custom addon collection feature. This way you can use it in a browser that isn't based on the beta/nightly branches, and should be less crashy. I run Fennec to access a few privacy redirect extensions, largely to make reddit and twitter less awful to browse without their respective apps.

Requires AMO registration

Re: Firefox Android now supports Tampermonkey

#244

Earlier quoted context omitted.

As far as I know you can install any addons you want, you just have to create your own collection. Those default addons you see are only Mozillas standard collection. Even do I would like there were more addons to choose from as default I can understand Mozillas choice here. And that is that most addons are not design for android and they would not work or give a very bad UX. So for many non tech savvy standard users…

>As far as I know you can install any addons you want, you just have to create your own collection. I'm also very interested in bypassing the mobile limitation. Does creating a custom collection require an account? Ive never seen the option and have tried everything to back to 2019-2020 Firefox plugin capabilities. Update: For anyone in the same position, I just saw this solution in another comment. Its unfortunate t…

You have to jump through several hoops, but it is worth it. https://gxvwb.dev/how-to-install-firefox-add-ons-on-android/

Re: Firefox Android now supports Tampermonkey

#245

Earlier quoted context omitted.

Reading further down that issue, it doesn't seem to be what it initially sounded like. ?

Still wild to reserve permission to to that

doing that would be flat out unlawful under the GDPR, regardless of whatever crap they put into their EULA

and enough to get that company into rather expensive trouble

Re: Firefox Android now supports Tampermonkey

#246
post #5

Greasemonkey was the good one and then something happened with it and it was no longer the best choice. I'm not sure what. The same repeated with Tampermonkey. It now has telemetry built into it, at one time w/ no privacy policy. https://www.reddit.com/r/firefox/comments/6hs59w/tampermonke... The good one now is Violentmonkey. Has been for some time. Does Mozilla have an allowlist for these? If so I don't like it.

I just checked the addon in its settings. Yes, it has telemetry. No, it isn't enabled by default. Its opt-in. That's how I want such a feature implemented (e.g. Homebrew doesn't, it uses opt-out).

Re: Firefox Android now supports Tampermonkey

#247

Earlier quoted context omitted.

what's the difference between the old and new firefox android browser? is it a separate codebase? different UI?

Completely new codebase yeah. The old codebase is known as Fennec and is directly based on Gecko (the browser engine that powers desktop Firefox). All the same advantages. The UI wasn't excellent, but it did the job perfectly well. The new codebase is known as Fenix and is instead based on GeckoView which isn't an actual browser but rather an library version of Gecko that is intended to replace Androids own System We…

Part 1 due to comment length:

> but rather an library version of Gecko that is intended to replace Androids own System WebView

Not literally, though. Yes, the idea of packaging up the rendering engine inside of an Android library with a proper Java API was likely modelled on the implementation of the system web view, but I don't think that offering a literal drop-in replacement was ever the goal. Literally replacing the system web view is impossible anyway unless you're building a custom version of Android, and even just offering an API-compatible replacement (which would mean probably having to emulate quite a bit of Chromium/Blink-specific behaviour with Gecko) seems of dubious value [1] compared to the additional effort required for building such a thing.

> there's a bunch of features missing since a WebView browser isn't made with those in mind the same way a regular browser is.

I think that's not so much the Webview-inspired technical design, but simply the fact that Firefox on Android always seemed chronically under-staffed. Even with the old Fennec codebase there were some comparatively and surprisingly major bugs and missing features (didn't remember your scroll position if the memory pressure evicted either background tabs or the whole Firefox process, under memory pressure session history would stop recording entirely for tabs that had been unloaded once [2], you couldn't re-order tabs in the tab list, and quite a few more) that remained open for sometimes years and were in quite a few cases only fixed because of outside contributions.

So then they went and did the Thing You Should Never Do [3], i.e. throw away the existing codebase, which of course meant that all and every little feature and UI nicety that finally got added throughout the years (and sometimes only because of outside contributions) got thrown out, too, and had to be re-implemented from scratch. And what with the Android browser still not being all that generously staffed and having to re-write the whole browser from scratch, it means that any progress beyond the MVP state will necessarily be slow and very intermittent.

> Firefox Fenix is terrible, has been terrible for the past 2 years and I don't understand why they're still developing it instead of shoring up Fennec properly.

The problem was that due to being chronically under-staffed (and also because of Fennec's design with a native Java Android UI [4] meant that you got at least the UI responsiveness benefits of multi-process even without actual Gecko-side multi-process capability), they never got around to doing the whole work of making Gecko on Android multi-process ready and only finally did it as part of the GeckoView/Fenix total rewrite. Given the time that has passed since development on Fennec stopped (and as far as Gecko was concerned, it stopped even earlier because they eventually shunted off Fennec to the ESR branch, which coincidentally meant putting a relatively fixed termination date on Fennec, regardless of how good or bad Fenix would be coming along one year hence +/- a few weeks [5]).

Much as I'm unhappy about Fenix and nostalgic for Fennec myself – if you somehow were able to drum up sufficient manpower for making a real dent in the bug backlog, I suppose that at this point it'd be more efficient finally re-implementing all those missing features back into the Fenix codebase, rather than attempting to get the old Fennec codebase working with a current Gecko build again.

[1] Shipping a custom browser engine (i.e. Gecko) along with your app immediately bumps your APK size by dozens of MB, so unless your app is actually a browser itself, you probably need to have a really special use case and be quite desperate to start considering that option instead of using the system web view which comes at no size penalty.

[2] Either the Firefox developers themselves didn't actually use their browser that intensively, or maybe they all had phones with much beefier specs and therefore never experienced the behaviour on a memory-constrained device. That particular bug got introduced in Firefox 16, got its first bug report for Firefox 24 and amassed seven duplicates before it was finally fixed in Firefox 46, but even that only because I got so fed up with it that I finally investigated and then fixed the issue myself.

Personally I'm not complaining that much about that turn of events, because it got me starting to contributing to Firefox for a while which was nice as a hobby, plus I got an invitation to the San Francisco all-hands out of it, which was nice, too (both meeting the Mozilla developers, as well as the trip itself), but for the management of the whole Firefox on Android project itself it doesn't speak quite that well…

[3] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

[4] The very first Firefox on Android actually did use a HTML/XUL-based interface just like Desktop Firefox does, but they found that on a phone the performance of that approach was terrible enough that they decided to rewrite the UI as a native Android app (codename "Native Fennec"), which then became Firefox on Android until version 68 and the replacement by the Fenix codebase.

[5] I suppose in a real pinch they could have extended the life of the 68.x ESR branch a bit more, but only if Fenix would have been in a really catastrophic shape at that point.

Re: Firefox Android now supports Tampermonkey

#248

Earlier quoted context omitted.

what's the difference between the old and new firefox android browser? is it a separate codebase? different UI?

Completely new codebase yeah. The old codebase is known as Fennec and is directly based on Gecko (the browser engine that powers desktop Firefox). All the same advantages. The UI wasn't excellent, but it did the job perfectly well. The new codebase is known as Fenix and is instead based on GeckoView which isn't an actual browser but rather an library version of Gecko that is intended to replace Androids own System We…

Part 2 due to comment length:

> It appears to have gotten so bad that they moved the entire issue tracker over to Bugzilla and moved the repo to a new GitHub repo to hide just how feature poor this browser is.

The move to Github with Fenix probably happened because all the cool kids are hanging out on Github these days and they were hoping to gain some additional outside contributors that way. On the other hand, while Github's UI is in some ways possibly a bit slicker and more polished than Bugzilla's, Github's issue tracking is still lacking some notable features that are present in Bugzilla, like proper dependencies between individual bugs. Plus development of Gecko and GeckoView still happens in Bugzilla, so while using Github for Fenix might make things easier for outside contributors, it also introduces some additional friction for Mozilla's own developers.

As for the repo move – from what I remember around the time that the whole GeckoView thing started, they (or at least certain product managers) were dreaming of being able to develop figuratively (or maybe even literally) dozens of little special-purpose browsers along the lines of Focus. Like one special privacy browser (i.e. Focus), one special browser for watching videos, one for… I can't remember actually, but maybe for online shopping, one for doing "research" or something like that, and so on, and so on, and so on.

That's why the old Firefox actually got split up not just two-way, but actually three ways: GeckoView (Gecko packaged up with a proper Android API instead of the sprawling ad-hoc API in browser.js), Android Components (common UI components for web browsers as another separate library) and then the actual browser itself (because like I said the original idea was to have dozens of separate little browser apps, so they wanted to have as much re-usable code as possible – not just the browser engine itself, but also any other components that would be part of the native Android app – things like the URL bar, tab management, downloads, menus, sync, etc. etc.).

It's an admirable goal, but it also introduces quite a bit of additional friction – instead of building the browser in one go, you now need to build three separate projects. I suppose for pure Android developers it's nice not having to directly deal with Gecko [1], but if you're doing things that straddle those component boundaries, it's rather annoying. You have three separate repositories that you need to keep in sync, you need to wrangle three separate builds, when landing new cross-component features you need to land them across those separate repositories in the right order and with the right timing, Gecko development is still tracked on Bugzilla while the two Android repositories used to use Github… [2] And what with the additional split of even the Android app into Android Components and the actual app, even pure Android developers who didn't work on Gecko/GeckoView couldn't entirely escape this additional friction.

And of course (YAGNI was true this time), Mozilla never really got further than building the two browsers that are existing even now (Focus, which still seems to be hanging on, as well as the main Firefox itself [3]), so I guess that ultimately they themselves decided that having two separate repositories (or three, if you're counting Focus, too) wasn't actually worth the hassle, so they decided to merge them back together again in order to make the developer experience more seamless.

[1] Though Firefox has been able to build in "artefact mode" for quite a while now (definitively pre-dating the Fenix rewrite), where it'll simply download a Gecko build from Mozilla so you don't have to compile the C++/Rust code yourself if you don't have any intentions on making any changes in that area. So from an Android developer point of view there's not much of a difference between building the old Firefox for Android with an artefact build, or building the new Firefox with a ready-made GeckoView package, though I suppose the new systems allows you to skip some "Mozillaisms" that are still required for building the full Firefox repository even in artefact mode, plus of course you no longer have to download the whole large mozilla-central repository.

[2] Apart from the general annoyance of feeling that Spolsky was definitively right and throwing out the whole old codebase was a mistake, this was another reason why I stopped contributing to the frontend bits of Firefox on Android – I used to contribute both frontend and backend bits, and in conjunction with the general annoyance about the direction being taken, suddenly having to deal with three separate repositories didn't feel like fun any more.

[3] Okay, so there was Firefox Rocket, too [4], which was supposed to be some sort of lite browser for developing countries, but with the release of the full new Firefox it was discontinued again. (And shipping it with Gecko(View) instead of using the system web view would have definitively taken it out of the "lite" category, too.)

[4] And the "Reference Browser" I guess, but that was only ever intended as a demo project for Android Components and possibly to also aid in debugging without having to spin up a full Firefox for Android build, or before the new Fenix-Firefox was even in a really useable state.

Re: Firefox Android now supports Tampermonkey

#249

Earlier quoted context omitted.

What exactly is better in ViolentMonkey? Just want to know because I keep working with userscripts and after GreaseMonkey's collapse TamperMonkey has been my default userscript manager.

TamperMonkey has a terrible embedded editor. It assumes 4 spaces formatting and some other shit that I don't like, but can't change. I'm also lazy to switch to something else. I just wish they would fix the editor.

Oh the days when user scripts were simply files on your hard disk and could simply be directly edited (and e.g. also globally searched) by the text editor of your choice…

Re: Firefox Android now supports Tampermonkey

#250

Earlier quoted context omitted.

My guess is they are afraid they might lose Google money if they enable too much freedom. But they have also been losing users, and without users they have no leverage.

I use some addons that weren't whitelisted trough the addon collection trick. Many addons plain don't work. The mobile browser doesn't have the UI these addons rely on and maybe there's some API coverage missing. I considered this a fair reason when the rewrite was released, you could still use the old Firefox for a while. But then time passed and nothing changed. It's clear the Fenix devs don't have the capacity or…

> Many addons plain don't work. The mobile browser doesn't have the UI these addons rely on and maybe there's some API coverage missing.

Even the old Fennec code base never fully supported all bits of the Webextension API, and yet there were no restrictions on add-on installation. Besides in any case it would have been up to add-on developers to decide whether they could sensibly get their add-on to work on Android (and therefore mark it as officially compatible with Android on AMO), or whether some crucial API was missing (or they simply didn't feel like re-designing the UI with small screens in mind) and therefore leave it as officially desktop-only.

Simple page scripts don't require any APIs (and especially no UI!) beyond basic Webextension support at all, and yet e.g. the video-background-play-fix add-on was only whitelisted after comparatively ages and much user complaining.

And even before Webextensions, when writing an Android add-on required quite a bit more separate code that couldn't directly be re-used from a desktop add-on (due to the UI and e.g. tab management being handled differently between Desktop Firefox and Fennec), AMO still had much more Android add-ons available than the current measly 22 add-ons that can officially be installed.

Post reply on HN