New Feature Request: Temporarily "Disable on this Site"

[rugaM]

Environment

I've notice the lack of this function while running ABP 1.9.1 on a Google Chome 43.0 and on Firefox 39.0, both on OS X 10.10.4. But the issue would be applicable to ABP 1.9.1 running on any browser and OS.

The problem

Some websites have been using a trick to "bypass" AdBlock: selected features do not work when AdBlock on. For example, you may not be able to comment, like or share a post/video/picture. Then you temporarily disable ABP on that website, use the said feature, and switch ABP back on. But the thing is, there is a chance you may forget to switch it back on! Happens to me all the time. And this is what these websites are counting on to bypass Adblock.

Proposed UI change

To make it as intuitive and user-friendly as possible, I suggest to add an option to temporarily disable ABP on a particular website. By default, this would disable ABP on that website for, say, 5 min. To satisfy advanced users, we could have an option to customize the duration of the timer under ABP's "Options".

User Interface

On Chrome, an option labeled "Disable on this for 5 min" could be placed under "Enabled/Disable on this Website", which is seen when one clicks on the ABP icon in their browser (see attached mock-up). The change would be very similar in other browsers.

[rugaM]

feature mock-up

[rugaM]

In terms of UI, an alternative is to have one text that would change from "Enabled on this site" to "Disabled on this site for 5. min" to "Disabled on this site" and back to "Enabled on this site", as the user clicks on it.
ps: I am new to this, so excuse me if this text is super lame. :)

[mapx]

as @rugaM noted on forum, something similar (temporary filters) was discussed time ago
​https://adblockplus.org/forum/viewtopic.php?f=4&t=6184

[greiner]

Instead of defining an arbitrary time, wouldn't it make more sense to allow disabling ad blocking for the current session so that it would get reenabled again automatically after you leave the site?

However, we'd have to consider that we're planning to bring more options to the icon popup when we get around porting it to Firefox , namely "Disable on this page" and "Disable everywhere" (see #1436).

[rugaM]

What do you mean by "leave the site"? If I have multiple tabs open on the same site, would it be tab specific? If it involves closing the browser altogether, to me would be almost the same as "Disable on this page", since I never close my browser. I see your point, and I very much like the idea of simplifying things for the user. But since people may have multiple tabs open these days and some never even close their browsers anymore, I was wondering if your suggestion would not create confusion.

[trev]

Yes, I think that my suggestion in the forum doesn't make too much sense - who knows when the session ends, could take weeks. On the other hand, we could have an option "Disable Adblock Plus in this tab," so Adblock Plus would continue working everywhere else and closing the tab would automatically restore original behavior. Problem here: while this is fairly easy to implement in Firefox, in Chrome and especially in Safari this might be problematic (Sebastian might know more).

[greiner]

Sorry for the confusion. With "leave the site" I didn't mean "when the browser session ends" but whenever the top level frame of a tab gets unloaded either by closing the tab, closing the browser or navigating to a different domain (or maybe even a different page) within that tab.

From the docs:

• Detecting when a tab is closed
  • Chrome: ​chrome.tabs.onRemoved
  • Safari: ​SafariBrowserTab.addEventListener("close", onClose, false)
• Detecting when a tab's location changes
  • Chrome: ​chrome.tabs.onUpdated
  • Safari: ​SafariBrowserTab.addEventListener("beforeNavigate", onNavigate, false)

Note that we already have logic in place in Chrome and Safari for forgetting tabs when they close and for assigning a new Page object when a tab gets loaded.

[sebastian]

Adding an option to "temporarily" disable Adblock Plus for the lifetime of the page (top-level document) would be trivial. We could simply use a PageMap object which already does the abstraction. However, this would be useless if you need to reload the current page first after disabling ad blocking, or when it is required to have ad blocking disabled for an operation that involves navigation.

Disabling Adblock Plus for a tab (across navigation) seems to be more useful. Yes, it would be possible to do so even on Safari. Though the tab abstraction is leaky there. But that doesn't matter for this use case, as we wouldn't need to distinguish between active and pre-rendered pages of the same tab. However, this approach would still introduce quite some complexity, as the abstraction layer currently doesn't consider tabs but only pages.

Regarding the UI/UX, I'm not sure whether adding yet another way to disable Adblock Plus wouldn't rather confuse more users than users this feature is actually helpful for. I don't have a strong opinion though.

[sven]

For me this sounds like an edge case, which should be manageable with precise white-listing. This should be possible with the "Disable on this page only" method under Firefox. You will not see that option in Chrome, Safari or Opera, but we're working on that.

To implement a time-wise white-listing seems to be very confusing for the majority of our user base. A "Disable Adblock Plus in this tab" functionality seems to me more reasonable, but i assume that the feature parity of our popover menu will have a higher priority than adding new features into our popover.

[Jerryteacup]

Sorries for bumping a fairly old thread, but I also call for a temporary disabling feature.

I feel a session specific temporary disabling would be good enough.

To me the temporary disabling sounds like a very reasonable way to fight against sites that detect ad-blocking software. The thing is they WILL push their ads down our throats, that's why the adblockers are detected.

I wouldn't find it problematic to temporarily disable ABP every time I visit a site. It would be a very, very small nuisance at worst.

[mapx]

also #1332

[greiner]

Closing this ticket in favor of ​ui#2.