Unify disabling and enabling menu items among platforms.

[sergz]

Firefox	Chrome	Internet Explorer
[✓] "Disable on some.domain"	✓ "Enabled on this site"	[✓] "Disable everywhere"
[✓] "Disable on this page only"	✘ "Disabled on this site"	[✓] "Disable on some.domain"
[✓] "Disable everywhere"

Where [✓] means that ✓ is shown only when ABP is disabled.

There are several points:

• In Firefox one can disable ABP for the single page as well as for the whole web-site, meanwhile in Chrome and in IE one can disable only for the whole web site.
  Do we need the ability to disable ABP on a particular page on other platforms?
• In FF and in IE the item text contains the domain while in Chrome it's called "this site".
  Do we need the domain here?
  
• In Chrome the text is changing, "Enabled"<>"Disabled" (the indicative mood, past tense), in FF and in IE it's always "Disable" (the imperative mood). It may be related to some platform specific behaviour and expectations. When the user clicks on the menu item in Chrome it's still here, while in FF and in IE it becomes hidden.
  What should be the text and checkboxes?

Why is it important?

Beside the consistency among the platforms, it influences on the working process because different people see it differently what creates unnecessary discussions in the code review and additional technical troubles. So, it would be very useful to have some reference which we can use.

What to do?

For the present we need to decide how it should be and then we can create the following issues for each particular module.

[sergz]

I personally like how it's done in Chrome.

• I think that for the user it's better to have the fixed number of item texts and (s)he does not care about the domain.
• In Chrome when the user chooses to enable ABP on this web site we remove all filters which disable ABP on the current page which is actually what user expects, and for her/him the domain is not important here.
• Of course the technical factor should not hurt the quality of the UX, but it also not so good to show any domain in the menu item. Even if we can be sure that it cannot inject anything, there are always possible troubles with the localization and broken layout.
• As pointed by @Eric in the code review

  This change set is fixing #1104 by deriving the domain name in the engine,
  but it's not the same as that displayed in the popup menu. That's a defect.
  Given the need for consistency between what the user sees and what the engine
  does, it would be better to derive the domain on the plugin side. It would be
  possible to do it the other way, but that means a channel from the engine to the
  plugin, which is problematic. Alternately, it would be possible to derive the
  domain name in the same way in both the plugin and the engine separately.
  

  it's very easy to get inconsistency between the created filter and the displayed domain. At least when we create the filter we remove the prefix www. if it exists. So, to prevent any questions regarding the inconsistency between what the user sees and the actual filter it's better to say "on this site" and say that any transformations on the URL or domain are done for good.
• JIC, I would like to add that we should not create mental association that disabling on this site is mapped to one exception filter. We can change filters structure later but keep the functionality.

[eric@adblockplus.org]

Whatever we do, we should be displaying a domain name to the user, rather than only a referential phrase such as "this site". I find it preferable to say "... this site (foo.com)" rather than merely "... this site" with out the annotation.

[greiner]

This is something that Sven put the most thought into so it'd be helpful to hear what he has to say about it.

I'd just like to give you some context: When we redesigned Chrome's icon popup we replaced the enable/disable checkbox with a toggle button. The next step for us is to apply that same design to the Firefox version (see #181 and more importantly #1436), the progress of that has stalled, however, but will be picked up again soon.
To ensure compatibility with the Firefox version we agreed on having three options (as outlined in #1436):

• Disable on this page
• Disable on some.domain
• Disable everywhere

@Sven IIRC this won't be implemented in the form of three separate toggle buttons. It'd be great if you could add more detail to that issue to clarify how it should appear and behave.

Next up will be #1461 which will make those options also available in Chrome/Opera/Safari.

Generally, we don't want to remove existing features so the current consent is to use the options as outlined above.

[sven]

I just added the latest firefox popover menu to ensure that we're talking about the same thing. (btw: we should get rid of the term bubble ui and use the official UI term, which is popover, for it)

A unification is not possible since we have different possibilities within the different browsers. Like greiner said, we don't want to remove features which we already implemented. At the moment it's the case that we have more features and possibilities under firefox than under chrome. The right way would be to implement the features from firefox also for chrome instead of trying to unify something which is not completed in other platforms.

So to answer the questions from the issue:

# 1: Do we need the ability to disable ABP on a particular page on other platforms?
IMO yes.

# 2: Do we need the domain here?
This site and This domain are two different options. Because we don't want to confuse people with the wording domain and site we prefer to show the current domain like shown in the firefox_bubbleUI_v11.png​. So yes.

# 3: What should be the text and checkboxes
See firefox_bubbleUI_v11.png​

[philll]

This seems to be a pure discussion issue without any specific change request. Thus it should belong into the (intra)forum and not in the issue tracker.

[greiner]

Agreed. What it seems to boil down to is that we should make IE's enabling/disabling options more consistent with what we have planned on other platforms already. Everything else is already being taken care of - except for Maxthon.

[sergz]

I disagree that it should be in intraforum and why is it rejected?

Regarding intraforum:

• it's better to have at least technical decisions in one place
• there is nothing secretive and we can always give a reference to this issue
• now we can create blocking tickets for each platform to unify disabling and enabling menu items, and it's clear why we need these tickets.

Regarding rejected, it looks non-logical to have tickets which block rejected issue.

[greiner]

I rejected it because, as philll mentioned, it doesn't propose any specific changes. Not sure what you mean with "tickets which block rejected issue", though, since this one's not blocked by any other issue.

Re: Intraforum

I'd also prefer to have those discussions be held publicly online but the issue tracker doesn't seem like the right tool for that. The intraforum is the best we have so far since the only other option is our public forum in which, however, only a small subset of our team is actively involved in, unfortunately.