Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#2699 closed defect (invalid)

strange counter behaviour

Reported by: mapx Assignee:
Priority: Unknown Milestone:
Module: Platform Keywords:
Cc: sebastian Blocked By:
Blocking: Platform: Chrome
Ready: no Confidential: no
Tester: Verified working: no
Review URL(s):

Description (last modified by mapx)


windows 7
chrome 44.0.2403.52 beta-m (64-bit)

How to reproduce

-go to
-the ABP counter will show 1 ad blocked
-press ctrl-shift-J (go into console)
-the ABP icon counter will show 2 ads now
-repeat the steps: close developer tools, go again into console ==> the counter will increment its value every time

If easyprivacy will be add to the filter lists the counter will be always set on 4 (even going into console).

Expected behaviour

the counter should show 1 in all cases (keeping only easylist subscription)

Change History (3)

comment:1 Changed 5 years ago by mapx

  • Description modified (diff)

comment:2 Changed 5 years ago by mapx

  • Description modified (diff)

comment:3 Changed 5 years ago by sebastian

  • Resolution set to invalid
  • Status changed from new to closed

The request in question has following URL and would load a subframe:…&u_cd=24&u_his=2&u_tz=120&u_java=true&u_nplug=8&u_nmime=10&frm=0&url=https%3A//

This request is blocked by the filter /googleads. in EasyList. It seems that when you open the devtools in Chrome, requests for blocked frames are repeated. I also realized that the subsequent requests initiated when opening the devtools are reported with the type other instead sub_frame.

The adcounter in Adblock Plus behaves correctly here, as it effectively blocks additional requests when opening the devtools. If anything this is a Chrome bug, that it sends requests again when opening the devtools.

Last edited 5 years ago by sebastian (previous) (diff)
Note: See TracTickets for help on using tickets.