Opened 3 years ago

Last modified 3 years ago

#3631 new change

External flag to use CSS injection or traverser.

Reported by: sergz Assignee:
Priority: Unknown Milestone:
Module: Adblock-Plus-for-Internet-Explorer Keywords:
Cc: Blocked By:
Blocking: Platform: Unknown / Cross platform
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description

Background

In order to make #119 we need to make a decision about that external flag.

  • do we really need it?
  • should it be done before or after the changeset https://codereview.adblockplus.org/6567422169448448/?
  • when do we need to read the flag value (on initialization of plugin or engine, on each call of CPluginTabBase::IsCSSInjectionEnabled?
  • where should it be stored (some additional file in app data directory, registry, prefs.json)?

Currently

Developers can insert return false; into CPluginTabBase::IsCSSInjectionEnabled or add some code to read it from some file (3 lines of code) or use something else.

What to change

It will be added after answering the questions above.

Change History (1)

comment:1 in reply to: ↑ description Changed 3 years ago by sergz

Please find my opinion below:

  • do we really need it?

Yes, we do need it. We can mainly use it to enable such functionality only for a certain part of users to begin with because it's a significant change and requires an extensive testing.

It does not matter, can be committed afterwards.

  • when do we need to read the flag value (on initialization of plugin or engine, on each call of CPluginTabBase::IsCSSInjectionEnabled?

Plugin should read it on plugin initialization. However initially it can be read by the engine, though it looks overengineering.

  • where should it be stored (some additional file in app data directory, registry, prefs.json)?

It should be in the registry, we use already HKEY_CURRENT_USER, L"Software\\AdblockPlus" key for some settings.

Note: See TracTickets for help on using tickets.