Undo Manager should have lower listener priorities

[Marek Lewandowski]

This is a follow up of #12327.

Current implementation is really fragile to code execution order. If undo manager is initialised before some code that cancels keydown undo manager's listener will be executed, but if the order is opposite, then it won't.

The listeners should be added with low priorities (999), so they are always handled at the end - if nothing else handled them.

Changes in ​branch:t/12332.

[Artur Delura]

Undo manager bind events with priority 10(default). There is a chance that some plugin bind same event with same priority. So now callback execution depends on order of binding callbacks to events. There is a chance that callback in undo plugin is called first and then other callback is called and stop() event. In this situation our callback shouldn't be called. To avoid such situation we lower priorities of callbacks in undo plugin - just to be sure that stopping event in other part of code prevent our callback execution.

How about:

I think we could see at this problem from global perspective. This problem could be handled in events library. I.e. throw an error/warning when there are two callbacks binded with the same priority, and one of them stop() event execution. Of course only in development version.

Or to provide extra flag which inform that some callback can stop() event. And then this callbacks will be handled first.

Changes in ​branch:t/12332.

[Piotrek Koszuliński]

I think we could see at this problem from global perspective. This problem could be handled in events library. I.e. throw an error/warning when there are two callbacks binded with the same priority, and one of them stop() event execution. Of course only in development version.

In some (or even most) cases it will be totally correct. As long as the order of listeners does not depend on some external condition, like plugins loading order, this situation is clear and stable.

Or to provide extra flag which inform that some callback can stop() event. And then this callbacks will be handled first.

Then, why not using high priority, instead of setting this argument?

I don't see a big problem here as long as we are aware of possible problems and we prevent them (just like in this ticket).

[Piotrek Koszuliński]

Fixed with ​git:ea48ac5.