Issue 3868 - Use the new FilterNotifier API

Issue 3868 - Use the new FilterNotifier API

[kzar, 2016-03-24 11:23:08]

As discussed in IRC, if we made the filter notifier pass the name of the event
to callbacks we could reduce some boilerplate here. For callbacks that need to
listen to multiple types of notification it would simplify things. Anyway if
that's a good idea or not is debatable, and as you pointed out we would only use
that in a couple of places. Also it would require further changes to
adblockpluscore, so I'm inclined to agree that it's not worth the trouble for
now at least.

LGTM

[Sebastian Noack, 2016-03-24 11:58:37]

On 2016/03/24 11:23:08, kzar wrote:
> As discussed in IRC, if we made the filter notifier pass the name of the event
> to callbacks we could reduce some boilerplate here. For callbacks that need to
> listen to multiple types of notification it would simplify things. Anyway if
> that's a good idea or not is debatable, and as you pointed out we would only
use
> that in a couple of places. Also it would require further changes to
> adblockpluscore, so I'm inclined to agree that it's not worth the trouble for
> now at least.

Well, I only see one single case here where the listener would actually benefit
from having the action, that is in the requestBlocker module, where we have to
wrap the listener in order to identify *.disabled actions. Also we added some
additional boilerplate in the devtools module, but I think that way, it's
actually cleaner, and FWIW more efficient, there. And these are just the
minority of use cases, while every other listener doesn't care about the action
at all.

[Sebastian Noack, 2016-03-24 15:30:21]

I've updated the dependencies, and adapted Port to use the new listeners()
method rather than accessing private APIs. New patch set is up.

[kzar, 2016-03-24 15:38:25]

LGTM