Cannot UPDATE Assets
uBlock-user opened this issue · comments
Open Assets page
Click on the small clock icon near all the listed assets
Click Update Now
Logger - https://i.gyazo.com/b907ee4d347ef79bf54032775d605ad5.png
Network tab - https://i.gyazo.com/cda125798608e9e425207298899ad31f.png
Disabled all other extensions and still the same case - https://i.gyazo.com/d14fec4788956d5c2dac632b26bc1dbd.png
popUI - https://i.gyazo.com/44e402218a6ad279f62cf4ddcfdaf2f4.png
uMatrix version - 1.3.7.3
Chromium 67
I'm able to update uBlock Origin's FilterLists so it's not my connection either.
Yes, sorry.
Can you try the rule matrix-off: chrome-extension-scheme true?
Adding that worked. But I didn't have that in 1.3.7.1 and it worked there, so how come it won't here ? Also the scheme is behind-the-scene as per the popUI - https://i.gyazo.com/44e402218a6ad279f62cf4ddcfdaf2f4.png
I'm just investigating for now, not saying this is the definitive solution.
Well, I just looked at the code, matrix-off: chrome-extension-scheme true is part of the default ruleset at installation.
What changed is that now uMatrix, just like uBO, will re-classify behind-the-scene network requests for which a context is provided. This context is something new that was added in Chrome 63, so that now uMatrix can properly filter behind-the-scene network requests. This has always been available on Firefox, but was not used by uMatrix until now.
Consider #684 (comment): now uMatrix can properly deal with this, the network request which was formerly left unfiltered can now be filtered, because now uMatrix is told that the "initiator" of the behind-the-scene network request is https://thedisconnect.co.
The current issue is a side effect of this fix: the "initiator" in the current case is the extension URL: chrome-extension://[extension id], hence why matrix-off: chrome-extension-scheme true is needed.
Now the real issue is the logger not informing properly about this, it still shows the network request as being from the behind-the-scene scope, while it has been re-classified internally. I have been planning to fix this along with #951, which I have been wanting to fix since a while now, but haven't had the time yet -- I want the logger to provide the context in which network requests were made, just like in uBO, and from there it will become easy to diagnose/fix issues like the current one.
The current issue is a side effect of this fix: the "initiator" in the current case is the extension URL: chrome-extension://[extension id], hence why matrix-off: chrome-extension-scheme true is needed.
So we will have to add that rule otherwise all behind-the-scene requests will be blocked unconditionally ?
Now the real issue is the logger not informing properly about this, it still shows the network request as being from the behind-the-scene scope, while it has been re-classified internally
That means the scope it should have shown in the popup UI is chrome-extension-scheme instead of behind-the-scene ?
Removed matrix-off: behind-the-scene true and added matrix-off: chrome-extension-scheme true and it still works. So behind-the-scene is now chrome-extension-scheme ?
I was just trying to explain what is happening, I did not make a decision yet about what I will do if I decide to do something.
Well for now, matrix-off: chrome-extension-scheme true will be required to be added(if not present already) untill you decide, that's for sure.
As said above, it's in the default ruleset.
I meant for those who removed it, since it didn't affect untill now.
Until I fix the logger, behind-the-scene network requests made in non-network URI contexts will not be reclassified.
So it's still an incomplete fix ?