Add devtools panel showing blockable items

[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.

[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.

[philll]

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?

[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

[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.

[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.

[trev]

Oh, I forgot:

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

[sebastian]

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.

[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).

[sebastian]

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.

[sebastian]

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

[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.

[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.

[sebastian]

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

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

[sebastian]

​https://hg.adblockplus.org/adblockplusui/rev/52e67e506bd6
​https://hg.adblockplus.org/adblockplusui/rev/49ac049b2b2f
​https://hg.adblockplus.org/adblockpluschrome/rev/0835a84d047c

[Ross]

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