Inconsistency of the icon requests counter on Github

[Mikey1993]

Steps:

1. Enter to any issues page on Github (for this reproduction, lets use uMatrix's issue page: https://github.com/gorhill/uMatrix/issues)

2. uMatrix is showing X amount of requests that the page made in the icon counter and the matrix cells itselves - lets call this number X. Take a note of this number.

3. Enter to any issue thread on this page (lets say right click on the "Support RTL languages" issue) - number of page requests (uMatrix) got changed on the icon counter and the matrix cells (as expected) - this number will be Y. Take a note of this number.

4. Head back to the issues page with the mouse back button.

5. Notice that icon counter of uMatrix hasn't changed - still showing the Y number.

6. Click on the matrix - See that the amount of requests in cells that is shown is the one that you had on the issue page "Support RTL languages", the previous page, not the current page. (it isn't the Y or some higher number as I believe it should be).

Note 1: After some time being idle on the page, the matrix icon counter can update and synchronize the correct amount of request.

Note 2: I think this is caused because of the caching mechanism that is used by Github (something like SPF on YouTube maybe), and uMatrix isn't really dealing with it properly.

[gorhill]

Ok we need to stick to uMatrix here, I am having a hard time making sense of what is reported. uBlock is rather different than uMatrix internally, and it is confusing me more if you report both -- which have different behavior -- as a single issue.

I did see there was a problem with uMatrix not updating its badge. I think I got it fixed but I need to known exactly if this was the issue you reported, for now I can't figure exactly what you are reporting with uMatrix. Can you remove all references to uBlock so that I can clearly see what you are reporting with uMatrix?

To save time, regarding 6): uBlock may block more than what appears in the request log, because it is not uncommon for the same net requests to be fired more than once. So each time a specific net request is blocked it is counted as +1, even though it will be reported once in the request log. That would be impractical to repeat the same URL many times in the request log.

[Mikey1993]

Sure thing, I have removed the references to uBlock on the issue.
Is this more clear?

And about your reference to uBlock:
Then how about a counter in the statistics page to correct the misunderstanding that could cause someone to think that uBlock isn't reporting the right number of blocked URLs?
Though, the issue that was reported here with uBlock is that the statistics that are being reported after going back on Github are totally wrong (not changing accordingly to the page shifting), and not about the number of accounted net requests on a given page in the statistics tab.

[Mikey1993]

I am also able to reproduce this issue on GitLab:
https://gitlab.com/fdroid/fdroidclient

When clicking on one of the top bar pages and going back with the mouse button.

[gorhill]

Ok, so at 5)-6) this is what I fixed: the badge wasn't updated. This was a case of the URL changing in the address bar, but no document load occurring.

Re uBlock: it works quite differently than uMatrix. In uBlock, the stats are not reset when the URL in the address bar changes, they are reset when a new document is (re)loaded. Resetting uBlock stats whenever the URL changed was really annoying in some heavy cases of pages which change incrementally. Best example is Google Maps.

Currently uMatrix is completely URL-based, so whenever the URL changes, a new internal data structure to hold matrix stats is created. This is annoying on site such as Google Maps. I think I may need to revise that to be more like uBlock, i.e. reusing internal data structure when the URL is updated without the main doc in the page being reloaded.

[gorhill]

Oops, the second fix hides the first fix.