Ublock: Elements incorrectly detected as 'other' in Palemoon

[0strodamus]

OS: Arch Linux x64
Browser/version: Pale Moon 26.2.2
uBlock Origin version: 1.7.5rc1+

Issue:
Image, script, and stylesheet elements are intermittently detected by the logger as other when "*$third-party" rule is used.

Issue reproduction:
1) create uBlock Origin rules *$third-party and @@||webcube-general.s3.amazonaws.com/eizo$image,script,stylesheet,domain=eizo.com
2) navigate to site with allowed 3rd party content, ie http://www.eizo.com/library/basics/eyestrain/
3) logger will show blocked images, scripts, and stylesheets which were detected as other

Resolution:
revert the following changes made to vapi-background.js in version rc1:
"Services.obs.addObserver(this, 'http-on-modify-request', true);" > "Services.obs.addObserver(this, 'http-on-opening-request', true);"
"Services.obs.removeObserver(this, 'http-on-modify-request');" > "Services.obs.removeObserver(this, 'http-on-opening-request');"

[gorhill]

Unable to reproduce:

Any other extensions installed?

[0strodamus]

Thanks for the reply and for trying to reproduce the errors. I do have other extensions installed. To eliminate them as possible suspects, I retested in Virtualbox with a brand new profile and the only installed extension was uBO. I repeated my tests using both my compiled version of palemoon 26.2.2 and the binary version provided by the palemoon project. My results were the same with both browsers and matched what I reported originally. These are the details of the tests I performed and results I obtained.
These are the settings I used:

These are the only 3rd-party filters that I enabled:

These are only rules I used:

*$third-party
@@||webcube-general.s3.amazonaws.com/eizo$image,script,stylesheet,domain=eizo.com
@@||d3d2dcrnm26w9u.cloudfront.net/eizo$script,stylesheet,domain=eizo.com

This log snippet shows some scripts blocked while others are allowed:

This log snippet shows some images blocked while others are allowed:

After reloading the webpage, most elements are allowed, but a few are still blocked:

I then installed a "hacked" uBO version where I reverted the "http-on-modify-request" code changes back to "http-on-opening-request" and all the elements that should be allowed were allowed:

This an entire session log captured after first launching the browser and navigating to http://www.eizo.com/library/basics/eyestrain/ without reloading the webpage: log.txt

I hope this additional info helps and you can reproduce the issue.

[gorhill]

I am still unable to get all these wrongly typed other entries with your steps. The only other requests I get are legitimate ones, i.e. from the browser, from uBO (re. auto-update), or from favicons.

What would be useful is to find out if others can also reproduce.

I tested using Palemoon 26.2.2 64-bit Linux from that page.

[0strodamus]

Thanks for testing again. The binary you used is the same one I tested with (directly extracted to /opt/). I created a post in the palemoon forum. Hopefully another user will be able to validate what I'm seeing here.

Is there any harm for me to just continue reverting the "http-on-modify-request" to "http-on-opening-request" in vapi-background.js? I know it may not work long-term, but are there any problems using the current version like this?

[gorhill]

There is no harm using http-on-opening-request, aside that this makes uBO incompatible with NoScript.

[ghost]

I was also able to reproduce a number of 'other' requests in the logger on the page http://www.eizo.com/library/basics/eyestrain/, using:

• Linux Mint 18 (Cinnamon 64-bit beta) live DVD running in VirtualBox
• Pale Moon 26.2.2 (64-bit) manually instaled from package
• uBO 1.7.5rc3 w/ no modified settings whatsoever

[gorhill]

I can reproduce after I removed my local installation of uBO 1.7.5rc3, and instead installed 1.7.5rc3 directly from the developer channel on AMO. Edit: I can also reproduce now with my local development version of uBO -- it seems removing uBO before re-installing it was necessary for me to reproduce.

The same issue is not present in FF 47.

Investigating.

[gorhill]

Observations:

It appears that the delay between calls to shouldLoadListener and http-on-modify-request is larger than the delay between shouldLoadListener and http-on-opening-request -- well on Pale Moon at least (and possibly earlier versions of FF). This causes the pending request ring buffer to overrun -- i.e. shouldLoadListener uses ring buffer slots faster than they are serviced at http-on-modify-request time.

The pending requests ring buffer is currently set at 32 slots. Extending to 128 slots appear to fix the issue. I could set it at 256 slots for added peace of mind.

Edit: that successive reload of the page made the problem less worse is probably because http-on-modify-request was fired faster for resources already in the browser cache.

[gorhill]

The issue was also affecting uMatrix on Pale Moon -- with the added quirk that the problematic network requests were also seen as behind-the-scene.

[0strodamus]

@thegoodthings: Thanks for validating!
@gorhill: Thanks for investigating and fixing the issue. I really appreciate it.