Opened 6 years ago

Closed 4 years ago

Last modified 4 years ago

#154 closed change (fixed)

Add devtools panel showing blockable items

Reported by: sebastian Assignee: sebastian
Priority: P3 Milestone: Adblock-Plus-1.11-for-Chrome-Opera-Safari
Module: User-Interface Keywords:
Cc: trev, fhd, arthur, mapx, jobp, greiner Blocked By: #1740, #1801
Blocking: #3596 Platform: Unknown
Ready: yes Confidential: no
Tester: Ross Verified working: yes
Review URL(s):

https://codereview.adblockplus.org/6393086494113792
https://codereview.adblockplus.org/5646124035604480
https://codereview.adblockplus.org/29335261
https://codereview.adblockplus.org/29335396

Description (last modified by sebastian)

Background

A fair amount of users on Chrome and Opera would like to have a list of requests that can be blocked, like the "blockable items" we show on Firefox. This is useful to get aware of blocked requests and requests that can be blocked, in particular those that don't have a visible element.

What to change

Implement a devtools panel, showing a list of requests processed by Adblock Plus on the inspected page. Also list applied element hiding filters. Highlight items that are already blocked or whitelisted accordingly. And allow users to block and whitelist requests listed, as well as removing user-defined filters.

Change History (36)

comment:1 Changed 6 years ago by philll

by fhd:

Isn't that a bit much info for the small bubble? We could alternatively inject something similar to what we have in Firefox to the page and show it at the bottom (should be fine legal-wise, CMIIW @TimSchu). Alternatively we could put it on a new tab.

by arthur:

Why should there be any legal issues?

by palant:

I agree with Felix, this content is definitely out of place in the bubble. Not only is it too much content for the bubble, it is also advanced content - most users have trouble interpreting these URLs. My original idea was adding a developer tools panel via chrome.devtools.panels API1. Unfortunately, it doesn't look like opening this panel programmatically is possible.

This approach won't work with Safari of course and from what I can tell there is no similar functionality there. I would rather not inject content into the webpage, even if legally not problematic. If nothing else works I would open a new tab for the blockable items.

Note that UI isn't the only problem, actually getting the content to display is just as problematic. We want to log actual webRequest calls here, not deduce the URLs from the content which is rather unreliable. Yet simply logging all calls will easily lead to memory leaks as we had it with the Firefox extension originally. This is why the current implementation of requestNotifier in Firefox binds the data to document nodes - if the nodes are removed the data will also be gone. We need to do something similar in Chrome and Safari.

by fhd:

We need to be careful about injecting anything into the page in general - removing parts of pages is fine legally, adding stuff is a grey area. Apparently it's fine as long as it's obvious that it's part of our UI.

comment:2 Changed 6 years ago by philll

  • Reporter changed from philll to sebastian

comment:3 Changed 6 years ago by arthur

  • Cc arthur@… added
  • in_progress set to 0
  • Ready unset

comment:4 Changed 5 years ago by mapx

  • Cc smultron45@… added

comment:5 Changed 5 years ago by philll

  • Cc trev fhd added

We don't seem to generally agree on this issue but rather reject it. Somebody willing to make a final decision to get rid of this zombie?

comment:6 Changed 5 years ago by mapx

zombie ???
...and the chrome users will never have a blockable items list (when initially it was said that all the features in ABP for firefox will be implemented in chrome too) ?

for example it could be an editable list like that implemented by kiss privacy extension
https://chrome.google.com/webstore/detail/kiss-privacy/lfopjlendebbnfddpgpoaahmpbgmffii?hl=en

Last edited 5 years ago by mapx (previous) (diff)

comment:7 Changed 5 years ago by sebastian

@philll: That is just not true. Getting Adblock Plus for Chrome/Opera/Safari on par with the features we have in Firefox (including this one) is one of our long-term goals. The outcome of the discussion above was just that it might not make sense to have the list of blockable items in the bubble, but on separate page or integrated in the developer tools.

comment:8 Changed 5 years ago by trev

@mapx: Yes, in its current state it's a zombie - there is no agreement on an approach here, meaning that nobody can work on it.

IMHO the alternatives discussed are:

  1. Put blockable items into the bubble. I already explained above why I don't consider this a real option.
  2. Use chrome.devtools.panels API. As explained above, there is an issue here - opening the panel programmatically isn't possible. Also, it won't work in Safari.
  3. Open the list of blockable items in a new tab. The user experience is suboptimal but it will work on both Chrome and Safari and it can be opened programmatically.
  4. Some combination of all these options, e.g. show the list in the devtools but open a new tab when we need to open it programmatically or on Safari.

It seems that we would have to start with the third alternative either way. After that we can still investigate to what degree it makes sense to integrate it into the devtools or the bubble.

comment:9 Changed 5 years ago by trev

Oh, I forgot:

  1. Inject blockable items into the webpage content - definitely the worst possible option.

comment:10 Changed 5 years ago by sebastian

  • Description modified (diff)
  • Ready set

Considering all the points that came up during the discussion, I agree that showing the list on a separate tab is the only suitable solution. I have updated the description of the issue accordingly.

Last edited 5 years ago by sebastian (previous) (diff)

comment:11 Changed 5 years ago by philll

  • Platform set to Firefox

comment:12 Changed 5 years ago by mapx

  • Component changed from Unknown to Platform
  • Platform changed from Firefox to Chrome

comment:13 Changed 5 years ago by fhd

  • Component changed from Platform to User-Interface
  • Platform changed from Chrome to Unknown
  • Summary changed from Showing blockable items in the bubble to Showing blockable items

comment:14 Changed 5 years ago by fhd

  • Priority changed from Unknown to P4

comment:15 Changed 5 years ago by mapx

  • Cc arthur mapx added; arthur@… smultron45@… removed

comment:16 Changed 5 years ago by mapx

well, it's an old change request ... and a very requested feature.

I guess it would be - for beginning - very useful (and less complex) to have the list of the triggered filters (and items addresses).

In a second moment it could be added the other part (select [multi] elements and block requests / create filters).

Last edited 5 years ago by mapx (previous) (diff)

comment:17 Changed 5 years ago by sebastian

  • Owner set to sebastian
  • Priority changed from P4 to P3

I just started working on it. But currently I'm in the favor of implementing it only as devbuilds panel for Chrome and Opera.

That way we can easily log requests only while the panel is in use and only for the pages it is used on, saving memory and CPU time. Note that we can't really associate the requests with document objects as we do on Firefox to mitigate memory leaks. And even if we could, that wouldn't help in scenarios where pages send XMLHttpRequests every few seconds.

Also I don't think anymore that we need a way to show blockable items programmatically. This is a quiet advanced feature, that IMO doesn't have to be linked in the popup, but rather belongs into the devtools anyway. Moreover, I consider it a rather poor user experience to show blockable elements in a separate tab, if we can use a panel on the corresponding page instead.

Last edited 5 years ago by sebastian (previous) (diff)

comment:18 Changed 5 years ago by sebastian

  • Blocked By 1740 added

comment:19 Changed 5 years ago by sebastian

  • Description modified (diff)
  • Review URL(s) modified (diff)
  • Status changed from new to reviewing
  • Summary changed from Showing blockable items to Add devtools panel showing blockable requests

comment:20 Changed 5 years ago by sebastian

  • Description modified (diff)
  • Summary changed from Add devtools panel showing blockable requests to Add devtools panel showing blockable items

comment:21 Changed 5 years ago by jobp

  • Cc jobp added

comment:22 Changed 5 years ago by greiner

  • Cc greiner added

comment:23 Changed 5 years ago by sebastian

  • Review URL(s) modified (diff)

comment:24 Changed 5 years ago by sebastian

  • Blocked By 1801 added

The latest patch is based on the URL refactoring from #1801, which we probably should merge first.

comment:25 follow-up: Changed 4 years ago by RypeDub

I like how people are saying that this could cause legal issues. Ever heard of GreaseMonkey or TamperMonkey? Ever seen any addon ever? There are tons of addons and extensions for the multitude of browsers that offer changing content of a website / webpage as it's loading and after it's fully loaded.

You can't get in trouble by any one for promoting and assisting users modify and alter their web surfing experience.

We aren't hacking the websites and injecting XSS or SQL or JavaScript code into the pages that allow these functions, we are modifying things after / as they are being downloaded onto our own computers.

I totally support this and I hope it gets introduced with the very next update as of this comment.

comment:26 in reply to: ↑ 25 Changed 4 years ago by fhd

Replying to RypeDub:

I like how people are saying that this could cause legal issues. Ever heard of GreaseMonkey or TamperMonkey? Ever seen any addon ever? There are tons of addons and extensions for the multitude of browsers that offer changing content of a website / webpage as it's loading and after it's fully loaded.
You can't get in trouble by any one for promoting and assisting users modify and alter their web surfing experience.

Unfortunately common sense doesn't always apply. ABP is the biggest browser extension and people certainly like to sue us - if anyone is in danger of getting into trouble for injecting content into a page, it's us, not GreaseMonkey. But as I said a year ago, to my knowledge we shouldn't have to worry about injecting something that's clearly part of our UI.

But that doesn't matter really, since we ended up going for the devtools panel anyway, for non-legal reasons IIRC :)

I totally support this and I hope it gets introduced with the very next update as of this comment.

Well, the patches are up and under review, that can sometimes take a while though.

comment:27 Changed 4 years ago by sebastian

  • Tester set to Unknown

The UI for the devtools panel landed: https://hg.adblockplus.org/adblockplusui/rev/bd1e7562306e

Integration into Adblock Plus for Chrome will follow (hoppefully soon).

comment:28 Changed 4 years ago by sebastian

  • Blocked By 3596 added

comment:29 Changed 4 years ago by sebastian

  • Blocked By 3596 removed
  • Blocking 3596 added

comment:30 Changed 4 years ago by sebastian

  • Blocking 3596 removed

comment:31 Changed 4 years ago by sebastian

  • Blocking 3596 added

comment:32 Changed 4 years ago by sebastian

  • Review URL(s) modified (diff)

comment:33 Changed 4 years ago by sebastian

  • Review URL(s) modified (diff)

comment:35 Changed 4 years ago by sebastian

  • Milestone set to Adblock-Plus-for-Chrome-Opera-Safari-next

comment:36 Changed 4 years ago by Ross

  • Tester changed from Unknown to Ross
  • Verified working set

Implemented and working. Been using it for about a day across Chrome and Opera and didn't notice any major issues, it works quite well. The list filters at the top work as expected and the buttons to add the filters are useful/easy to use.

As a user, I found the "Remove Rule" button slightly confusing at first after adding a blocking rule, then an exception rule on top of it as the button text doesn't change and it's unclear if it then removes just the exception rule or both rules (it's the first - The first press removes the exception rule and the second the blocking/hiding rule).

ABP 1.10.2.1557
Chrome 30 / 40 / 48 / Windows 7 x64
Chrome 48 / Ubuntu 14.04 x64
Chrome 45 / OS X 10.11
Opera 19 / 30 / Windows 7 x64
Opera 35 / Ubuntu 14.04 x64
Opera 30 / OS X 10.11

Note: See TracTickets for help on using tickets.