Loading…
[Firefox] Item count in badge does not reset when visiting a different page #1170
6 participants
I was not able to reproduce this. I have FF37 and ublock 0.9.3.0.
My test:
- surf to cnet.com. badge says "10"
- press ALT+D (i.e. click the address bar) and surf to amazon.com. badge now says 4
- repeat step 2, this time go to www.github.com. badge is now gone. (due to nothing being blocked)
Note that I only use 1 filterlist - EasyList.
It doesn't seem to happen in all cases. Here's one case where it seems to seems to happen all the time:
1) Click the 'uBlock' link at the top of the page (i.e. in "chrisaljoudi/uBlock"). The badge count should increase. It seems as though the new count is cumulative since instead of the badge disappearing and reappearing, it just directly increases.
2) Press Backspace / click Back to come back to this page. The badge remains unchanged.
3) Click the 'uBlock' link again. The count further increases.
I am using FF 37.0 and uBlock 0.9.3.0.
I saw this happening when I googled around. When I went back and visited another site the count was only growing and for some reason uBlock thought that all the requests were started from google.com (I tried to add a dynamic rule and it started with google's address, not with the sites domain I was actually visiting). Fx 36.0.4 + uBlock 0.9.3.0.
Confirmed, with @FatOrangutan's repo steps. It seems that the navigation when you click the uBlock link is being reported by firefox as "same page", in the same way as when you click an intra-document link that should just scroll a page. I'm investigating why this might be, and will then find a fix.
Are you sure you are not seeing this on 0.9.2.3? Please check if there might be some other difference between your tests, as I've just run the same tests on 0.9.2.3 and got the same results!
0.9.2.3 has been working quite well for me. At least the origin in dynamic rules has been correct the whole time. Can't say the same about 0.9.3.0 :)
Yes, but specifically, if you follow the repro steps #1170 (comment) do you see the counter only increase, the same as for 0.9.3.0?
@FatOrangutan is talking about GitHub, AFAIK this is known behavior as GitHub is loading content inside the same page. That's not a regression and has been discussed in some other issue (can't find it currently).
Further, I've just tested this in Chrome, and get the same effect, so I don't think this is Firefox specific.
From what I have tell, GitHub is doing something cunning which results in navigation which looks like it is going from one page to another (like following the uBlock link at the top of this page) being some horrible javascript-y mess that actually changes the content of the current page instead.
This is therefore reported by browsers (both Firefox and Chrome) as an intra-page navigation, and consequently uBlock doesn't reset the count.
This could be addressed by modifying vAPI.tabs.onUpdated so that it only actually updates the pageStore if the normalized URL is different. On the other hand, a comment in tab.js suggests that this may be intentional behaviour for Google Maps? I don't know, but we need to decide whether a page update that changes the displayed URL, but is internally done without a real new page being loaded, should count as a new page for updating the block stats or not.
@sander85 If there is a separate issue around dynamic rules that is specific to Firefox, or to 0.9.3.0, please raise it as a new issue (or it may actually be #1140)
I can easily reproduce the bug on Google. Search anything you like, visit one page, hit back button, then visit another. The counter on the badge is only growing. At the same time it works correctly with 0.9.2.3.
I'm not seeing that effect with Google, with 0.9.3.0. I searched for "example", and got a counter of 2. Clicked the first (wikipedia) link, and the count was 0. Clicked Back and the count remained 0. Clicked the second (thesaurus.com) link and the count was 12. Back, count goes to 0. Third link (twitter.com) and the count was 1.
If you can identify what dynamic filter settings (or any other settings!) is causing the issue, that would be very helpful. I tried just * * inline-script block, but that didn't reproduce it.
I'm using * * 3p block, but I can reproduce with inline-script too :/ I even disabled all normal filters and it's still only growing. The only way to stop it doing so is to disable advanced option.
Another test: I reenabled all normal filters and deleted all dynamic filters - same behavior, counter is only growing. I have no idea what this advanced option is enabling in the background but it somehow breaks something..
Hmm. Curious. So if you do a "Reset to default settings" and then just check the "I am an advanced user" box and make no other changes, then restart Firefox, you can reproduce that with Google? When you click the back button to return to the search results after visiting a page, does the counter stay the same, increase, or reset to zero? (For me, it resets to zero)
I did a backup of my settings and then performed reset + restart. I was unable to reproduce. Then I restored settings from backup and I'm still unable to reproduce, now it works as expected. So maybe it's some kind of an upgrade problem. I think I didn't restart Firefox after upgrading to 0.9.3.0.
Will try on another Firefox and just with a restart after upgrading to 0.9.3.0.
Yeah, I can now confirm that just restarting Firefox after upgrade to 0.9.3.0 fixes that problem for me. After restart everything is working OK again.
Great, thanks for letting me know. I found the other issue you mentioned for the github stuff, #722, so I think that can be ignored too.
@r-a-y: Could you confirm if restarting Firefox resolves the issue for you?
Unfortunately Firefox caches frame scripts 1051238 until restarted, so upgrading without restarting can be problematic if frameScript.js or frameModule.js is updated. It may be worth trying to have Firefox report that a restart is required, if we know that we are upgrading from an older version, just in case - what do you think, @chrisaljoudi?
Yes, that's it :)
Confirmed that restarting fixes things!
Sorry for wasting everyone's time on this. Also thanks @AlexVallat for linking to the Bugzilla ticket.
Thanks for letting us know, @r-a-y.
I'll leave this here in case we decide to revist it: according to MDN a possible workaround for frame script caching is to make the URL for the frame script unique. So something like:
frameScript: vAPI.getURL('frameScript.js?' + vAPI.app.version), at vapi-background.js#L779 might do the job. Hard to test, though.
When using v0.9.3.0 on FF37, the badge count does not reset when visiting a different page.
To duplicate, use v0.9.3.0, visit a few sites in a tab and watch the badge count. The count does not reset as you visit a new webpage. Instead, the count accumulates.
I think the commits to address #1122 broke this. v0.9.2.3 does not exhibit this problem.