Number of blocked requests on the extension icon appears few seconds late after the webpage loading stops

[ghost]

Prerequisites

• I verified that this is not a filter issue
  • Filter issues MUST be reported at filter issue tracker
• This is not a support issue or a question
  • Support issues and questions are handled at /r/uBlockOrigin
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue
  • Your issue may already be reported.
• I tried to reproduce the issue when...
  • uBlock Origin is the only extension
  • uBlock Origin with default lists/settings
  • using a new, unmodified browser profile
• I am running the latest version of uBlock Origin
• I checked the documentation to understand that the issue I report is not a normal behavior

Description

Number of blocked requests on the extension icon appear second or two late after the webpage load.

A specific URL where the issue occurs

https://www.google.com/

Steps to Reproduce

1. Disable all extensions and only keep uBO enabled.

2. Browse to google.com and wait for the page to get loaded and notice that number of blocked requests appear second or two after the page loading stops.

3. For the sake of comparision, install v1.9.14 side by side and run both versions together on google.com, notice that with v1.9.14, the number of blocked requests appears as soon as the page is loaded but the latest dev build version take a second or two for that number to appear.

4. Refresh the page few more times to be able to reproduce this issue at will.

Watch the video I have attached below which displays the bug when compared with version v1.9.14 side-by-side. Reproducible on Firefox too but I can't provide a video of side by side comparison due to Firefox not allowing to install two versions side by side.

Expected behavior:

Number of blocked requests on the extension icon appears as soon as the webpage loading stops.

Actual behavior:

Number of blocked requests on the extension icon appears after a second or two late after the webpage loading stops. This started happening after v1.9.14.

Supporting Evidence

https://i.gyazo.com/22ab15443943f1ca7254f1b022beab65.mp4

Your environment

• uBlock Origin version: 1.16.15rc0
• Browser Name and version: Chrome 70/Firefox 63
• Operating System and version: Win 10 x64 1807 build

[gorhill]

For two reasons:

1. By design because displaying the block count has the lowest priority among all the tasks uBO has to handle. It would be inefficient to give a higher priority to the badge on the icon, the assumption is that calls to the API framework should be coalesced for efficiency purpose.

2. Because uBO has to buffer results of the processing of network requests to ensure they are properly reported: uBlock blocking domain but not showing it in the dynamic filtering pane gorhill/uBlock#2053. The fix to this issue required to introduce a delay before deciding what document owns a network request.

[ghost]

Yeah but this wasn't the behaviour on 1.9.14, why is that ?

[gorhill]

Pointed out above: gorhill/uBlock#2053. Fixed in 1.9.16.

[ghost]

Ah, I see. OKay I will close it then.

[ghost]

I don't see the same behavior on uMatrix, doesn't it suffer from that issue ?

[gorhill]

uMatrix is less sensitive to the issue affecting uBO, so I did not port the journaling code in uMatrix.

uMatrix is less sensitive to the issue because unlike uBO, the slate is not cleared on page reload.

[ghost]

Can the delay timer be reduced a bit ?

[gorhill]

Why? It's just a cosmetic "issue", what would be the point to mess with code which works fine as it is?

[ghost]

Because seeing it appear after whole 2 seconds or so have passed, is visually annoying to me atleast(and would be to others who also start noticing it), no other reason.

[gorhill]

I am going to add an advanced hidden setting to control the timing of journaling.

[ghost]

Thanks for considering my plea.

[Thorin-Oakenpants]

@rjkpa FYI you can run concurrent firefox profiles, and even different Ff releases (as long as one is a portable version) - see https://github.com/ghacksuserjs/ghacks-user.js/wiki/2.3-Concurrent-Profiles

[ghost]

That's for running multiple profiles, not the same thing as I did on Chromium.

as long as one is a portable version

I'm on portable, but you can't run two versions of the same extension on a single profile like you can do on Chromium, Firefox won't allow me to install the extension whatsoever.

[Thorin-Oakenpants]

^^ Sorry for going off topic, but you can run two or more FFs - each has it's OWN profile (that's the point). No one ever said to use the same profile simultaneously, although I can see that installed versions would auto-pickup on existing profiles.

on a single profile like you can do on Chromium

I'm not a chrome user, so I have no idea what you did in chrome. Sometimes I assume people already know things. I do not use installed FF either, so not sure on running two or more different installed FFs versions, but definitely with portable (or only one installed) you can.

But you are right - you can't use the same profile concurrently. I never said you could. Read the wiki. I said you can run concurrent profiles (and thus this allows you to ALSO run concurrent FF versions).

Quote: me

"FYI you can run concurrent firefox profiles, and even different Ff releases"

I said profiles, plural, with an s. This allows you to run multiple firefox.exe's. End of story. If you want to badger on about it, I am not interested. Why do you keep harping on about chromium? Don't answer.

[ghost]

but you can run two or more FFs - each has it's OWN profile (that's the point).

I knew that, ofcourse. I prefer the chromium behaviour instead, as I'm a chromium enthusiast and I'm not willing to go that far for a browser that I do not use everyday.

[gorhill]

The new advanced setting has been added: requestJournalProcessPeriod, default to 1000 (milliseconds). This will be in next dev build.

[ghost]

Perfect, that works brilliantly! I set it to 500(ms) and the original behaviour is back, thanks a lot for adding this!