Is there a way to make uMatrix operate before uBlock?

[navidada]

My question is somewhat related to other questions that were asked before, but I still haven't found an elegant way of solving this.

It seems that uBlock is doing an extra work, when it scan network requests that were already blocked by uMatrix. I'm only talking about the computational inefficiency aspect, because both add-ons work superbly - allowing privacy and blocking adds, just not as efficiently as they could have worked together)

One option of solving this is having strict rules in uBlock (blocking 3rd party connections and so), but then one needs to configuring each site on both uMatrix and uBlock. [it's a tedious task when trying to repair broken sites]

But I'm wondering if there's a way that things will work like they were meant to work on HTTPSB, i.e. first, uMatrix blocks requests (based on it's rules and the user defined rules) and then uBlock only inspects the elements that were authorized by uMatrix. This will increase the efficiency and speed of loading sites because it will diminish the number of elements that needs to be inspected against some 60,000-100,000 filters of uBlock)

Is there a way of forcing Firefox to first operate uMatrix and only then uBlock?
Or maybe a way of syncing uBlock with the user-defined rules of uMatrix? So that after updating the rulest in uMatrix, they will automatically be adopted by uBlock)
Or maybe merging both add-ons to one add-on that operates in that manner? [I understand this is an enormous task, but I'm just trying to invoke a debate where people can offer other solutions]

[0xBRM]

Redacted: Misunderstood issue.

[gorhill]

This will increase the efficiency and speed of loading sites because it will diminish the number of elements that needs to be inspected against some 60,000-100,000 filters of uBlock

Do you have any benchmark to support that this is an issue?

Last time I measured I got an average of 200 us per request for onBeforeRequest in uBlock.

Only sound benchmarks must drive development, otherwise it's just more than likely coding effort will be wasted working on non-issues.

[navidada]

Maybe I don't understand the way these extensions work together, or maybe I didn't explain myself so good, so I'll try to give a specific example for what I'm saying.

I'm referring to the fact that if I leave uBlock with default settings (everything is gray) then no mater what uMatrix is blocking, uBlock will show that it also blocks some of the things uMatrix has blocked and it will also allow some of the things that uMatrix has blocked.
For example, arstechnica.com. My uMatrix settings are "only allow connections from 1st party and block all cookies", so in order for arstechnica to work properly, I need to allow it to connect to arstechnica.net. All other connections such as google.com, adobedtm.com, parsely.com, etc. are blocked. All in all there are 108 possible connection, 96 are authorized by uMatrix, the rest, 12, are blocked.
But when checking uBlock, it seems that uBlock checks all of these 109 connections, also the 13 which are blocked by uMatrix. Then uBlock decides to accept requests from assets.adobedtm.com, www.google.com, www.googletagservices.com, and blocks www.google-analytics.com, static.parsely.com, speed.pointroll.com, etc which were already blocked by uMatrix.
If uBlock is checking things that were already blocked it's using CPU power for nothing.

Of course one can create dynamic rules in uBlock which will be equivalent more or less to the ones created in uMatrix for this specific site. But this means that it needs to be done for every single site that is broken. One will need to unbreak sites in both uMatrix and in uBlock. Or accept that uBlock will sometimes do some extra work which will result in nothing.

What am I missing here?

[gorhill]

If uBlock is checking things that were already blocked it's using CPU power for nothing

So you are probably seeing this on a Chromium-based browser. With Firefox this does not happen if I am not mistaken. It's a browser issue really, not an extension issue. But even if you went to file an issue with Chromium devs, I doubt there is anything to do, because I assume it's currently done the way it is done because each extension is in its own process, and so they can all evaluate requests in parallel, and forcing them to work in sequence would mean to forfeit advantage of parallelism of per-process architecture.

[navidada]

I'm seeing this in Firefox.
Though I understand the logics behind the advantage of parallelism of per-process architecture. It's just that the diagram of "The filtering engine" in HTTPSB seemed very compelling and logical, though I didn't take into account the parallelism issue.

[harshanvn]

I am able to see the some of the blocked requests in both the extensions.

Steps to Reproduce

1. Open Request logger for both the extensions
2. Open New Tab and goto tomshardware.com

You will see same requests blocked in the both the extensions, as reported in their respective loggers

Config

uBlock v0.9.9.1
uMatrix v0.9.1.3
FF v38.0.5 & W8.1

[gorhill]

@harshanvn

Steps to Reproduce

What is the issue?

[harshanvn]

@gorhill
You will see some of the requests (like an image from tracking.tomsguide.com/beacon) is blocked by both the extensions, and the same can be seen in the above post's screenshot.

I am not sure if blocking the same requests in two extensions is the intended design..

[gorhill]

Ok I guess I understand how this works in FF. If a request is blocked content-side in shouldLoad, the other extensions won't see it. If the same request is blocked in the HTTP observer instead, other extensions will also be able to see it. That's the best explanation I can find. I believe many other blockers work at shouldLoad level, while uBlock/uMatrix work at HTTP observer level.