Issue 3478 - Hide genericblock and generichide from the composer

chrome/content/ui/composer.js

Index: chrome/content/ui/composer.js
===================================================================
--- a/chrome/content/ui/composer.js
+++ b/chrome/content/ui/composer.js
@@ -224,7 +224,7 @@
     for (let typeNode = E("typeGroup").firstChild; typeNode; typeNode = typeNode.nextSibling)
     {
       let value = typeNode.getAttribute("value");
-      if (value == "document")
+      if (value == "document" || value == "genericblock" || value == "generichide")

[Thomas Greiner, 2016/01/06 15:44:51]

What about "elemhide"? Similar to these options "elemhide" also only makes sense
for exception rules.

[Sebastian Noack, 2016/01/06 15:49:33]

Interestingly, "ELEMHIDE" is skipped above. So no checkbox is added. I wonder
why we treat elemhide differently from document here?

[Thomas Greiner, 2016/01/06 16:07:02]

I assume that's because the composer only creates rules for blocking filters.
While ELEMHIDE is used in the context of a blocking filter it only applies to
element hiding filters (which you'd need Element Hiding Helper to create).

So it seems that if we want to be consistent with the existing logic, we'd have
to treat GENERICHIDE the same way as ELEMHIDE and only consider GENERICBLOCK at
this part of the code.

[Sebastian Noack, 2016/01/06 16:15:10]

I wonder whether we should expose generichide and genericblock here at all. I
agree that it makes no sense to have generichide exposed, but not  elemhide
which is a superset of it. But having only genericblock exposed seems
inconsistent, besides the genricblock/generichide options being experimental
anyway. Here is a new patch set.

         disableElement(typeNode, type != "whitelist", "checked", false);
 
       if (!typeNode._defaultType)