Loading…
Please support Firefox for Android #524
21 participants
This would be great, I'd much rather use a more efficient blocker to block ads on a mobile device.
Hi,
I've tried installing uBlock on Firefox for Android, but it says that version 35.0 is not supported.
I would also like uBlock for Firefox for Android. The biggest reason I'm using Firefox on my Android is because of the availability of AdBlock Plus for it. And I've been hoping to replace it with uBlock, because performance issues on Android are far more visible than on the desktop.
Anyway, I want to thank the developers for porting uBlock to Firefox.
It looks to me it should just be a matter of adding the proper targetApplication entry in install.rdf. However I do not have a mobile device, so I can't check whether uBlock will work just fine once made installable on mobile Firefox.
I know that the mobile version has more differences from the desktop forks, but the problem is that I don't have a device either where I could test.
I can confirm it doesn't work out of the box on Android with Firefox 35. It installs, but no blocking is done, and settings are inaccessible.
Related, genymotion is able to emulate android devices in virtualbox.
It should be possible to use the Android emulator:
It's possible to use the Android emulator to develop add-ons for Android without access to a device, but it's slow, so for the time being it's much easier to use the technique described below.
https://developer.mozilla.org/en-US/Add-ons/SDK/Tutorials/Mobile_development
@stefanocaselli yes, modify install.rdf as gorhill said above
If you have a "spare" computer to use it with, Android-X86 will run without being slowed down by emulation.
I've started working on this. There are a couple of places where Fennec differs from desktop Firefox internally, preventing µBlock from working in its current state.
I was able to install on mobile as well by adding the android target application, but there wasn't any blocking and there were no options available to configure or open the extension. Hopefully someone can figure it out, a lightweight blocker like this would benefit cpu usage and memory on mobile devices to save battery life
A lot of the Firefox API for addons is subtly different for Fennec (e.g. there's no gBrowser object, the UI consists of native objects, context menus are handled differently, etc.). Hence the addon in its current state would seem to load fine, but completely fail to do anything.
Much of the conversion is mechanical (which I've done). One of the remaining issues is that I haven't yet found a working equivalent to addTabsProgressListener.
From what I can tell, uBlock only uses addTabsProgressListener for onLocationChange. (TabClose and TabSelect are both available on BrowserApp.deck). Could adding a listener for the ready event on the tab itself not substitute for the progress listener, just for location change reporting?
would be great if one of you manages to solve it, the main problem with ABP&co. with Fennec is the limitation to only one blacklist...
Hey folks, @ncalexan from the Fennec team here. We're happy to try to help get uBlock working in Fennec but we need a clear request. @AlexVallat says that uBlock just needs onLocationChange -- can you drop a link to the relevant code? We should be able to get you location change events somehow, some way.
@ncalexan I think you also need to be able to observe/inspect HTTP requests: https://github.com/gorhill/uBlock/blob/master/platform/firefox/vapi-background.js#L916
If someone could point me in the right direction as to how to write plug-ins and how uBlock works. I would love to help out, at least count me in for testing
My comment was in reference to @chengsun saying that he had already completed most of the work, but that a blocking issue remaining was addTabsProgressListener.
I found that the only use of the tabs progress listener was for onLocationChange: https://github.com/gorhill/uBlock/blob/master/platform/firefox/vapi-background.js#L313 so I was starting a discussion on possible alternatives.
I don't know if there are other issues apart from that, as he hasn't replied, and does not appear to have committed any code publicly yet.
@Deathamns is the dev to answer that kind of question, he ported uBlock to Firefox, so he should be able to answer this accurately.
Blegh. I just noticed that I misunderstood the purpose of the onLocationChange event handler -- it only calls vAPI.tabs.onNavigation, which as far as I can tell only keeps track of page stats. (Am I right, @gorhill?) We have no way of viewing those stats on Fennec at the moment anyway, so it's irrelevant. (I did just implement listening on "DOMTitleChanged", and I think that works, but as I said, I can't really tell.)
The ads do seem to be blocked though. Give my branch a test:
https://github.com/chengsun/uBlock/tree/fennec
The purpose of vAPI.tabs.onNavigation is to setup an internal data structure for what is considered a new web page. It is very important, as this create the context for the page, which context is used when filters have to be evaluated.
For example, the filter ||useless.com^$domain=example.com will be evaluated as "block network requests to useless.com which originate from example.com. The context is example.com here. This context is also required for cosmetic filters to work properly.
So whatever can be done to set up this context before a page loads will be helpful.
How would I install it? I can't find the xpi file
Edit. Never,one, I found it
@Marsfan:
test here https://github.com/chengsun/uBlock/releases/tag/fennecWIP1
or build your own XPI in the normal way (tools/make-firefox.sh all, then look in dist/build/uBlock.firefox.xpi)
Is there a website which requires such a filter that I can test on?
I found this filter in EasyList: ||amazonaws.com/ansible.js$domain=motherjones.com
So I loaded http://www.motherjones.com/, and I could see the following request being blocked: http://mj-tech.s3.amazonaws.com/ansible.js.
@gorhill: Ah thanks. Can confirm that in Fennec that request does not get blocked. I don't think the event is early enough.
From what mfinkle says in IRC, this is the earliest event that we can get in Fennec at the moment, short of injecting WebProgressListeners into each tab (which is complex and has unknown performance penalties). We could stick with what we have right now, try the WebProgressListener approach, or we can file a bug with the Fennec guys so they can expose an event for us. What do you think?
Filed Fennec bug for exposing new events here: https://bugzilla.mozilla.org/show_bug.cgi?id=1132280
@chengsun , I installed your WIP1 on my android and it blocked ||amazonaws.com/ansible.js$domain=motherjones.com and more . The page looked exactly like it did on my desktop Firefox.
@my-password-is-password how did you get the first image. I cannot find the button or any options for uBlock on Android.
@Marsfan , To get to the dev tools i typed out,
chrome://ublock/content/devtools.html
and for the dashboard,
chrome://ublock/content/dashboard.html
If you don't want to type it out you can send your self an email with those links and open it up in firefox on your phone.
@my-password-is-password thanks.
@my-password-is-password Why do I type chrome, isn't this firefox
@Marsfan chrome:// doesn't mean chrome browser.
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tutorial/The_Chrome_URL
@my-password-is-password:
The script gets blocked when refreshing the page (as uBlock remembers the domain name from before). However, it doesn't get blocked if you navigate to a different domain, and then back to motherjones.com again. uBlock associates the new domain name with the tab too late in the page load process.
So, if I've got this straight, the issue is that when you get an "http-on-opening-request" observer notification, the information that you are given does not include the source of the request, so you don't know what tab/page it is coming from, and therefore can't selectively filter on that basis.
uBlock desktop handles this by logging tab location changes, and assuming subsequent requests belong to the tab whose location has just been changed to? (I'm not entirely clear on following the code that bit)
I did find one interesting bit of undocumented info that the channel object you get from "http-on-opening-request" does actually contain the URI of the page that's requesting it:
channel.QueryInterface(Ci.nsIHttpChannelInternal)
channel.topWindowURI
However irritatingly I have not yet been able to make that work on Android, I'm still trying to track down the equivalent of HttpChannelBase.cpp.
I've done some more poking into channel, and there's an even better source of information.
channel.loadInfo.loadingDocument
This will be "chrome://browser/content/browser.xul" for the page load itself, but the page loading the resource for things loaded by a page. (loadInfo itself may also be null if it isn't for a page, for example when loading favicons)
This is an entry point for doing things like:
BrowserApp.getTabForWindow(channel.loadInfo.loadingDocument.defaultView).id
(on desktop I think the equivalent would be)
gBrowser._getTabForContentWindow(channel.loadInfo.loadingDocument.defaultView).linkedPanel
(Testing with the debugger I got an instance of BrowserApp just by Services.wm.getEnumerator('navigator:browser').getNext().BrowserApp, but I'm sure something more elegant could be arranged)
Anyway, the point being, if you can get all the info you need to construct a pageStore from the request itself, you don't need to rely on it being able to observe the location change before the request is intercepted.
if you can get all the info you need to construct a pageStore from the request itself, you don't need to rely on it being able to observe the location change
It's actually what was happening for a long time: when the request was one of the root main_frame, the internal data structure was set-up. However, I had to change this, and rely mostly on navigation events, because issue #516. But still, if the platform-specific code of a Fennec implementation calls the core's vAPI.tabs.onNavigation when it gets such a root main_frame, it seems to me all should work fine.
calls the core's
vAPI.tabs.onNavigationwhen it gets such a rootmain_frame
I was thinking more that when it receives a non main_frame request, it would update the pageStore to match the main frame that request belongs to.
So adding to the detail parameter where onBeforeRequest.callback is called:
parentUrl: channel.loadInfo && channel.loadInfo.loadingDocument && channel.loadInfo.loadingDocument.URL,
then in onBeforeRequest itself, adding:
// Ensure the page store is associated with the correct parent URL
if (details.parentUrl &&
µb.normalizePageURL(tabId, details.parentUrl) !== pageStore.pageURL) {
vAPI.tabs.onNavigation({
frameId: details.frameId,
tabId: tabId,
url: details.parentUrl
});
}
However, maybe I'm missing something on #516. Given that he doesn't mention the values of X and Y I couldn't be sure of reproducing it. I did try #525 and #630 though, both with and without this change.
Just to try and reproduce the issue, without adding any new code I changed the 'beforeRequest' context in https://github.com/gorhill/uBlock/blob/master/src/js/traffic.js#L53 so that pageStore.reuse would get called for the main_frame, and couldn't reproduce either of #525 or #630, even with https://github.com/gorhill/uBlock/blob/master/platform/firefox/vapi-background.js#L271 commented out so the navigation event would have no effect.
So, is it worth investigating this further? If it turns out navigation events can be avoided entirely, either through allowing pageStore.reuse on main_frame or otherwise, then that would be excellent. The difficulty is ensuring no regression for the issues it was originally intended to resolve, of course!
Just leaving a comment... I look forward to the changes that enable fennec support eventually being merged into this repository.
would be great if one of you manages to solve it, the main problem with ABP&co. with Fennec is the limitation to only one blacklist...
+1
In addition the the "one list" limitation, ABP on Fennec also has a bug when sometimes the content that should be blocked appears and is hidden only a few seconds later (so the requests are definitely being sent).
No need to say, I am available for testing on Android if needed.
I don't have any mobile devices, so I can't do much here.
Now, the platform-independent code should not be touched at all. Whatever quirk there is specific to Fennec should be solved solely using platform-dependent code. As said, from my remote point of view, I see it this way: if the URL of a net request is that of MAINFRAME type, and if there is a way to determine for sure that the MAINFRAME is top level, than the platform-specific code should call vAPI.tabs.onNavigation.
Touching the platform-independent code to accommodate something specific to Fennec is really not a good idea, as whatever change could destabilize all platforms. The code there has grown to address many issues over time, so changing anything in there is to be avoided.
So, is there a way for the platform-specific code in Fennec to know:
- Whether a net request is of type
MAINFRAME? - Whether the
MAINFRAMEnetwork request is the top level one? (and not from an embeddediframe)
If so, it does look to me once the two conditions are met when inspecting a network request, it's a matter of calling vAPI.tabs.onNavigation callback set by the platform-independent part of uBlock.
Before worrying about how to separate out any fixes between platforms, I would like to have it simply working. Then we can figure out the best way to isolate differences between browsers.
To that end, I would like to get to the bottom of why the existing platform code independent code in traffic.js and tab.js doesn't already do this for MAINFRAME requests. It does identify them, but specifically excludes them from assigning their URL to the pageStore, leaving this instead to the navigation handler (tabListener in desktop firefox, for example) to do.
In order to avoid introducing a regression, I would like to be able to isolate some steps which illustrate an issue that occurs when simply using the MAINFRAME request to assign the URL to the pageStore that is fixed by having the navigation handler assign the URL instead. That way I can repeat those steps with fixes for Fennec and validate that the solution works for the edge case that originally necessitated the navigation fix.
I will have a play around with embedded iframes, and see if that highlights anything.
So just #516, and not the others related to it? OK, so I couldn't reproduce that one exactly, not least because that file isn't available for download any more! I found another zippyshare file and could reproduce behaviour such that:
1. On page load, uBlock reports 5 requests blocked and 4 of 7 domains connected.
2. After clicking the Download Now button, uBlock reports 0 requests blocked and 1 domain connected.
That seems to match the issue as described, so I'm reasonably confident that if any fix for Fennec avoids that behaviour, then it isn't a regression.
So, testing that, and the motherjones.com amazonaws.com script test mentioned in earlier comments, I can confirm that fully working functionality can be achieved in Firefox without needing a navigation handler, using the code additions I mentioned in my previous post.
The question now becomes how to implement the fix so that it plays nicely with other platforms. First, though, this potentially could be made as a non-firefox specific change. Is there any reason why you can't look up the URL from the tab, given that you have the tabId for the request?
Adding to https://github.com/gorhill/uBlock/blob/master/src/js/traffic.js#L69 this platform independent code:
// Ensure the page store is associated with the correct parent URL
vAPI.tabs.get(tabId, function(tab) {
if (µb.normalizePageURL(tabId, tab.url) !== pageStore.pageURL) {
vAPI.tabs.onNavigation({
frameId: details.frameId,
tabId: tabId,
url: tab.url
});
}
});
appears to do the job perfectly well without needing any navigation event handers anywhere else. If there's a reason this is no good, then it probably means any firefox-specific fix based on the same idea wouldn't work too...
vAPI.tabs.get is asynchronous, this means there absolutely no guarantee that the call to vAPI.tabs.onNavigation will be made before the next request(s) have to be processed. Best is this is handled in the Firefox-specific code, when there is no need to make any asynchronous call, and to call directly vAPI.tabs.onNavigation when all the information is available, i.e. when:
- this is a
MAINFRAME - it is the root one
This is it.
Surely @Deathamns could provide the best insight as to where that Fennec-specific code should go ideally.
tabs.get is async in Chrome? Hmm. Having a look at the firefox implementation of it, it does seem rather heavy-weight too, if all you want to do is get the URL from a tabId. Might be an argument there for a simpler getTabUrl(tabId) function to exist...
Anyway, if you really want to stick with the navigation event-based approach for other browsers then I guess this can be done in firefox-specific code, but without modifying traffic.js it would be a bit inefficient, duplicating a bunch of code from onBeforeRequest which would then run twice.
For your suggestion of calling onNavigation when receiving the request for the root main_frame, surely this will then run into the exact same #516 errors we are trying to avoid? Instead, it must call onNavigation for requests which are not the main_frame, when the page that they are being called for is not the current pageStore.pageURL.
So, to do it only in vapi-background, what we would have to do is copy and paste the code in the traffic.js onBackground function up to pageStore = µb.pageStoreFromTabId(tabId);, then check if the pageURL is different and call onNavigation if it is. Then do the onBeforeRequest.callback call and let it do all the same pageStore looking up again.
simpler
getTabUrl(tabId)
Everything in Chromium API is async, except for onBeforeRequest, for obvious reasons. However simpler you can craft it, it will still be async.
duplicating a bunch of code from onBeforeRequest which would then run twice
It is mostly a noop if the tab is already bound, notice the code:
- the binding occurs only for top main frame network request (i.e. once per web page), and
- the binding occurs if there is no binding found
So "a bit inefficient" is a complete non-issue.
Everything in Chromium API is async
Wow, that's got to be a pain to work with.
OK, so in that case my proposed addition at https://github.com/gorhill/uBlock/blob/master/platform/firefox/vapi-background.js#L971 would be:
if (details.frameId === 0 && // Only items loaded from top level frame, not iframes
!(type === 'main_frame' && details.parentFrameId === -1)) { // Not main frame itself, only items loaded from it
// Ensure the page store is associated with the correct main frame URL
var mainFrameUrl = channel.loadInfo && channel.loadInfo.loadingDocument && channel.loadInfo.loadingDocument.URL;
if (mainFrameUrl) {
var pageStore = µBlock.pageStoreFromTabId(details.tabId);
if (pageStore && µBlock.normalizePageURL(details.tabId, mainFrameUrl) !== pageStore.pageURL) {
vAPI.tabs.onNavigation({
frameId: details.frameId,
tabId: details.tabId,
url: mainFrameUrl,
});
}
}
}
@Deathamns: could you take a quick look offer any comment too?
// Not main frame itself, only items loaded from it
You are losing me.
Why not calling vAPI.tabs.onNavigation only when the request for the root frame is being processed? What you propose add an overhead to every request, instead of just that of the root frame.
Why not calling vAPI.tabs.onNavigation only when the request for the root frame is being processed? What you propose add an overhead to every request, instead of just that of the root frame.
Because of #516, which was your whole reason for not calling pageStore.reuse on main_frame in the first place, wasn't it? In traffic.js, you specifically check for the root frame being processed, and specifically do not update the URL of the pageStore, by passing 'beforeRequest' as the context to bindTabToPageStats.
So, as I understand it, the original logic was:
- Root frame comes in, pageStore URL is updated to that page.
Then, as reported by #516, it is possible that a root frame comes in that should not result in the pageStore URL being updated, notably if you are downloading a file from the page. The logic was then changed to:
- Navigation event occurs, pageStore URL is updated to that page.
This is causing problems for Fennec because there is no navigation event that occurs before every possible content request for that page. Notably, the amazonaws script at motherjones.com. This means that for that request, the pageStore URL is wrong, as it wasn't updated by the root frame coming in (original logic) or by the navigation event (#516 revised logic)
My proposal is:
- Content request comes in, pageStore URL is updated to the URL of the main frame that the request belongs to (if it isn't already correct).
That means you don't need to rely on a navigation event occurring in the right order with respect to the content event, and you don't need to worry about file downloads or other main frame content requests.
I agree that it adds an overhead to every request, which is why I was quite keen to minimise it by using the pageStore that is already being looked up for every request by traffic.js anyway. Apart from that pageStore lookup, the additional overhead is a handful of direct property accesses, a normalizePageURL call and a string comparison (of the URL).
@AlexVallat I didn't really follow this thread, and I'm not in the mood to read it back, so what is the problem exactly that needs to be solved? But looking at it, this doesn't seem right for e10s:
channel.loadInfo && channel.loadInfo.loadingDocument && channel.loadInfo.loadingDocument.URL;
what is the problem exactly that needs to be solved?
Fennec (Firefox for Android) does not have addTabsProgressListener. It does not have any navigation event that can be used to call vAPI.tabs.onNavigation that will always occur before any httpObserver.handleRequest for content on that page. Therefore, any page content that is loaded before the first available navigation event (confirmed to be DOMTitleChanged by @chengsun) will not be evaluated in the context of the correct page URL. Rules with $domain components will therefore be incorrectly applied.
Simply send a synchronous request for every main_frame, and listen for the pushState, replaceState in the top document.
Just to give some perspective on #516... this bug is far from a showstopper: uBlock had been used for months before this was reported, and the problematic behavior occurs only when a user tries to download a document.
So re-enabling this bug should not be a showstopper for Fennec users, it was not for most users for months.
This means the simplest fix can be used for now. I would take care of this with this simple solution which is just a trivial change if I had a mobile device, but I unfortunately I don't. Longer term of course, trying to find a more permanent solution, but short term, have Fennec users access to uBlock, surely this is more important than that corner case.
So for now I just copied wholly vapi-background.js from Firefox port into platform/fennec and added the line to call vAPI.tabs.onNavigate when a root frame is processed. There is a script ./tools/make-fennec.sh all to build a package. The port should suffer issue #516 for now, but this issue is magnitude less worst than not having a functional blocker at all. If someone can try this.
@gorhill There are a lot of other fixes needed for a Fennec port, @chengsun has done all the work in https://github.com/chengsun/uBlock/tree/fennec and was just missing a way of dealing with navigation events. His branch already works as a functional blocker, but suffers from the issue of incorrect filtering of requests that occur very early, like the motherjones.com amazonaws example.
So I think any fix needs to go into that branch.
@AlexVallat Ok, somehow I got into my head that this was the only problem to fix for a Fennec port.
Lovely to see this is being worked on. Thanks for your hard work guys, I'd love to use Ublock on Firefox Android.
Here are my feedbacks and suggestions. Sorry for my pool English.
I have tested chengsun's version. Filter works almost perfectly and the performance is excellent. However, because of the difference between mobile and desktop version.
Something should be improved.
1.The dashboard opition should show in the add-ons setting.
2.The switch that choose to enable and disable on a site should be add to the menu of Firefox or address bar. (Just like the ABP on firefox mobile.)
3.The function that used to hide a specific element should be add. This may be difficult to port to android, because it needs to use the touch screen. But it is very useful and convenient.
@Deathamns: I probably won't have time to work on it further any time soon, so I'd be happy for you to merge this before it bitrots completely. Obviously there are still the issues mentioned above, but we can always build on it later.
@Deathamns just tested, it installs but no longer blocks anything.
Same results as @TheReverend403 (tried XDA and the quick tests)
https://github.com/gorhill/uBlock/blob/master/platform/firefox/vapi-background.js#L369 should be
tabId: getOwnerWindow(win).BrowserApp.getTabForWindow(win).id,
Alternatively, the whole onFennecLocationChange handler can be removed following @gorhill 's implementation https://github.com/gorhill/uBlock/blob/70488274b1d1a1ddfbdafd5c5ad65a2a55871dac/platform/fennec/vapi-background.js#L1102 if we don't care overly about #516 (which is not such a big deal). See also my comments earlier in this issue
Found some other bugs too. Probably easiest if I just point you at a version of vapi-background.js I've fixed up in a clone and you can grab it or diff from there: https://github.com/AlexVallat/uBlock/blob/master/platform/firefox/vapi-background.js
Cool. One other thing I spotted:
https://github.com/AlexVallat/uBlock/blob/master/platform/firefox/vapi-background.js#L436 should be
vAPI.tabs._remove(tab, getTabBrowser(win));
@AlexVallat In the above discussion @chengsun mentioned that WebProgressListener could be used in Fennec. If that is true, then it would solve the whole onNavigation issue (because it works exactly like in Firefox, except it needs to be attached to every tab). Someone should test that.
browser.contentTitle is available in Firefox too, however it is empty for tabs that aren't yet loaded until you click on the tab (usually after browser start). tab.label seems to always have something, I assume this is the case with Fennec too.
However if tab.label is broken in Fennec, then first you should test if browser.currentURI.asciiSpec is available in Fennec, because then we won't need a condition for the two platforms (since it works in Firefox).
@Deathamns tab.label is not available in Fennec. The only choices for getting the tab title are browser.contentTitle or tab.window.document.title (which I'd say is worse).
browser.currentURI.asciiSpec is fine, but I'm not sure how that helps us?
@AlexVallat browser.currentURI is available in Firefox too, so we don't have to use different code for the two platforms.
@Deathamns Unless I'm missing something, we aren't... https://github.com/AlexVallat/uBlock/blob/master/platform/firefox/vapi-background.js#L574
Or was there somewhere else you were thinking of?
@AlexVallat Sorry, I'm stupid. I looked at the wrong line.
I've coded up some UI support for Fennec, in my fork. In the Add-on Options there are now two buttons, one to launch the dashboard (what the Options button used to do), and one to launch the request log. This was necessary because Fennec only supports inline options, so it's not possible to just use the options button to go straight to the dashboard.
I couldn't find any way of separating out behaviour for Fennec and desktop firefox, which means you get the same inline options buttons on the desktop, but I don't think this is a big deal.
For the toolbar button, I've added a tools menu item. There is no icon, but it can display the number of blocked elements after the name in parentheses, so that information is not lost. There is no support for popups (and the screen area is probably be too small for them to be useful anyway) so I've had it open a new tab with the popup UI in it when you click the menu item. Obviously not as convenient as being able to see it, and the page it applies to, simultaneously, but it is at least workable.
It has required some plumbing changes to the non-platform specific code too, but nothing that should break anything else.
It has required some plumbing changes to the non-platform specific code too, but nothing that should break anything else.
Can I have details of where and why?
Can I have details of where and why?
In popup.js and messaging.js, to allow the popup to work as a tab, rather than a popup, I added support for passing in the tabId as a parameter, and for switching back to the tab it applies to when refreshing or launching the picker. I also added the tab title to it's window title, to make it easier to identify which tab it was for.
In popup.html, devtools.html and dashboard.html, to add a meta tag so that mobile browsers display them at a more appropriate viewport (effectively zoom level) by default.
I'm not sure whether it counts or not (or exactly what your policy is on localisable strings), but I added some new strings to en/messages.json too - they are only used by the Firefox specific code though.
I see some changes being made, when is it expected to be released?
@privacy1776, I'm pretty sure you could just install the dev release xpi (though the release notes don't mention Fennec support). Otherwise, you could build the xpi yourself, copy it to your device/s, and open file:///path/to/xpi in Fennec
I have installed the dev release, I figured out how to access the settings, but I'm unable to change or edit any filters, I suppose this is in the works as we speak
chrome://ublock/content/dashboard.html
I would like to see this happen. HTC One was very hard to root, can't use universal adblocker.
Official support will be in 0.9.1.0.
Thanks @AlexVallat, @chengsun, @Deathamns, and @gorhill !
I haven't chimed in on this thread, but I've been anxiously following it, and I'm very 
right now. Thanks everyone!
Simply amazing, gorhill and team. The ublock UI for Firefox on Android is simply phenomenal and the willingness to support more and more platforms is what cements ublock as my favorite adblocker. Keep it up
Hi,
please support Firefox for Android (adblock plus works on firefox for android)
thanks.
PS I can help with testing if needed.