Issue 6975 - Check for specific anti-circumvention subscription URL

Related to https://issues.adblockplus.org/ticket/6974

[Manish Jethani, 2018-09-23 11:39:28]

Patch Set 1

This is related to https://issues.adblockplus.org/ticket/6974

This fix would work for users who have reenabled the ABP filters list after
restarting the browser (see issue description). In the long run, like in ABP
3.5, this should be fixed on the UI side.

A UI-only fix right now would not activate the snippet filters for users who
disabled the ABP filters list, restarted the browser, and the reenabled it.

[Sebastian Noack, 2018-09-24 01:58:05]

As discussed on the issue rather than requiring external code to set the type
property (in the future), how about parsing subscriptions.xml within core, in
order to determine the type?

[Manish Jethani, 2018-09-24 07:27:48]

On 2018/09/24 01:58:05, Sebastian Noack wrote:
> As discussed on the issue rather than requiring external code to set the type
> property (in the future), how about parsing subscriptions.xml within core, in
> order to determine the type?

For 3.4 I think it should be OK to hardcode the URL of the anti-circumvention
list.

After the release we should evaluate the option of parsing subscriptions.xml in
core. It would have a cost, of course, and we would have to involve more people
in that decision.

[Sebastian Noack, 2018-09-24 13:03:10]

On 2018/09/24 07:27:48, Manish Jethani wrote:
> On 2018/09/24 01:58:05, Sebastian Noack wrote:
> > As discussed on the issue rather than requiring external code to set the
type
> > property (in the future), how about parsing subscriptions.xml within core,
in
> > order to determine the type?
> 
> For 3.4 I think it should be OK to hardcode the URL of the anti-circumvention
> list.

Fair enough, I guess. LGTM then.

> After the release we should evaluate the option of parsing subscriptions.xml
in
> core. It would have a cost, of course, and we would have to involve more
people
> in that decision.

Not necessarily. We don't actually have to load subscriptions.xml at runtime.
Webpack can bundle resources like that. However, then adblockpluscore itself
(not only the web extension) will depend on webpack. Alternatively, we might
want to change the format to JSON, and just use require(), that way it will be
bundled (through webpack) in the web extension, but keeps working without
webpack in a nodejs environment. Can you please file a follow-up issue?

[Manish Jethani, 2018-09-24 13:23:07]

On 2018/09/24 13:03:10, Sebastian Noack wrote:
> On 2018/09/24 07:27:48, Manish Jethani wrote:
> > On 2018/09/24 01:58:05, Sebastian Noack wrote:
> > > As discussed on the issue rather than requiring external code to set the
> type
> > > property (in the future), how about parsing subscriptions.xml within core,
> in
> > > order to determine the type?
> > 
> > For 3.4 I think it should be OK to hardcode the URL of the
anti-circumvention
> > list.
> 
> Fair enough, I guess. LGTM then.

Thanks!

Hubert, does this look OK to you?

> > After the release we should evaluate the option of parsing subscriptions.xml
> in
> > core. It would have a cost, of course, and we would have to involve more
> people
> > in that decision.
> 
> Not necessarily. We don't actually have to load subscriptions.xml at runtime.
> Webpack can bundle resources like that. However, then adblockpluscore itself
> (not only the web extension) will depend on webpack. Alternatively, we might
> want to change the format to JSON, and just use require(), that way it will be
> bundled (through webpack) in the web extension, but keeps working without
> webpack in a nodejs environment. Can you please file a follow-up issue?

Alright, let me open a new ticket.

[Manish Jethani, 2018-09-24 13:59:47]

On 2018/09/24 13:23:07, Manish Jethani wrote:
> On 2018/09/24 13:03:10, Sebastian Noack wrote:
> > > After the release we should evaluate the option of parsing
subscriptions.xml
> > in
> > > core. It would have a cost, of course, and we would have to involve more
> > people
> > > in that decision.
> > 
> > Not necessarily. We don't actually have to load subscriptions.xml at
runtime.
> > Webpack can bundle resources like that. However, then adblockpluscore itself
> > (not only the web extension) will depend on webpack. Alternatively, we might
> > want to change the format to JSON, and just use require(), that way it will
be
> > bundled (through webpack) in the web extension, but keeps working without
> > webpack in a nodejs environment. Can you please file a follow-up issue?
> 
> Alright, let me open a new ticket.

Done.

https://issues.adblockplus.org/ticket/6977

[hub, 2018-09-24 14:48:46]

I'm not very keen on hardcoding a URL, but if we want this working in 3.4, let's
have it.

LGTM.

But this issue should be fixed properly in next.