forked from enlightenment/efl
ecore: fix built-in event types generation
Summary: Ecore internally uses 10 events, from ECORE_EVENT_SIGNAL_USER=1 to ECORE_EVENT_SYSTEM_TIMEDATE_CHANGED=10. The Ecore.Event.Message_Handler singleton that holds the counter of events is initialized with -1. This is followed in _ecore_event_init() by ten calls to ecore_event_message_handler_type_new(), which increase the counter of event by one each. This results in an event counter to be 9 (-1 + 10) at the end of the initialization of ecore_events. This means that the next event to be created will have a value of 10, which will overlap with ECORE_EVENT_SYSTEM_TIMEDATE_CHANGED. As such, these two distinct events will be aliased and their associated handlers will be called at unexpected times, with unexpected data. By changing the constructor value from -1 to 0, we prevent this event aliasing. Fixes T6605 Reviewers: zmike, Hermet Reviewed By: Hermet Subscribers: cedric, #reviewers, #committers, zmike Tags: #efl Maniphest Tasks: T6605 Differential Revision: https://phab.enlightenment.org/D6894
This commit is contained in:
parent
db15b03472
commit
d1e4c6bab8
|
@ -290,7 +290,7 @@ EOLIAN static Efl_Object *
|
|||
_ecore_event_message_handler_efl_object_constructor(Eo *obj, Ecore_Event_Message_Handler_Data *pd)
|
||||
{
|
||||
obj = efl_constructor(efl_super(obj, MY_CLASS));
|
||||
pd->event_type_count = -1;
|
||||
pd->event_type_count = 0;
|
||||
pd->current_event_type = -1;
|
||||
return obj;
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue