Opened on 06/20/2015 at 08:51:43 AM
Closed on 06/22/2015 at 03:47:38 PM
Last modified on 06/22/2015 at 03:47:57 PM
#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)
Environment
windows 7
chrome 44.0.2403.52 beta-m (64-bit)
ABP 1.9.0.1456
easylist
How to reproduce
-go to http://www.inoreader.com/feed/http://feeds.arstechnica.com/arstechnica/index?format=xml
-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)
Attachments (0)
Change History (3)
comment:3 Changed on 06/22/2015 at 03:47:38 PM by sebastian
- Resolution set to invalid
- Status changed from new to closed
The request in question has following URL and would load a subframe:
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.