Disallowed command should be disabled by changing its state

[Piotrek Koszuliński]

This is follow-up of #9829.

Currently when command isn't allowed its exec() method blocks it. It should rather be blocked by being disabled what will be more semantic.

[Frederico Caldeira Knabben]

Pushed t/10072@cksource.

To make this happen we need to change the behavior of commands, making them disabled by default (instead of "off").

Still we have tests failing now, but there is a good probability that it is just an issue related to the tests, not to the implementations. I'm not putting it on review because of this.

[Piotrek Koszuliński]

I checked the code and... have mixed feelings :).

This is that kind of patch which I understand, but I don't understand :D. Changes in code are clear for me, but not their implications.

PS. I'd avoid creating 2 functions for each cmd#checkAllowed method. Value may be cached in cmd object - we'd save some memory.

PPS. Filter#check caches results for string based tests.

[Piotrek Koszuliński]

I pushed fixes to dev and tests.

However, the last patch for tests proves that this solution may be incomplete.

All commands start as disabled.

Then on i.a. 'mode' event commands are refreshed. This event is fired after 'load' but just before 'instanceReady' (that's why test in clipboard/paste.html was failing - it is executed on 'load').

But after 'instanceReady', all newly added commands aren't refreshed. This caused the dialogadv/dialog.html test to fail.

For 99% of cases current solution should be sufficient. But I can imagine that this 1% may cause big WATFs :). We could solve this problem by automatically refreshing all commands added after 'instanceReady'.

[Piotrek Koszuliński]

I'm R+ing this issue now to speed things up, but we may fix issue mentioned in comment:2 after ticket is closed.

[Piotrek Koszuliński]

Fixed on major with ​git:013be3c on dev and c5dfe82 on tests.