@tasn
I didn't understand exactly what do you mean by "a new widget" ? do you mean all new interface stuff (ex : ui_text) or something else ? if so, no need to work on bugs related to the new interface ?

@tasn
At least it is not working for EFL_UI_TEXT_EVENT_CHANGED_USER event for selection in ui_text (i think there is others).
This is the code used in ui_text :

This patch will solve a bug I found in efl_ui_text.
efl_ui_text can't get the focus using mouse clicks when not focused.
mouse clicks will never move focus to efl_ui_text because efl_input_processed_set(pointer, EINA_TRUE) will make event flag = EVAS_EVENT_FLAG_ON_HOLD.

@cedric @zmike any comments?

@bu5hm4n
For example "_elm_entry_efl_access_text_string_get" function in elm_entry.c
call word end then call next character for "EFL_ACCESS_TEXT_GRANULARITY_WORD" case.

@bu5hm4n
This is what I thought also, but when I saw textblock test code i thought that this behavior are intended to be like this.
anyway in GTK word end for 'hello' is 5 not 4.
So I need to fix word end bug and remove all workarounds for it and commit it as a new patch

@bu5hm4n
It sounds a little bit wrong to me also but in "evas_test_textblock" they check word end to be 4 not 5 (not exact values but same case).
For elementary_test -to "Entry 4" i didn't see its code but it seems like it uses entry, entry does not export functionality for word end I think.
I already saw some code in entry for word selection or moving cursor by Ctrl+Arrow, it calls textblock word end then move to next character :)

@bu5hm4n
based on current behavior
If cursor at position zero or middle of the word and asked for word start and end , word start is 0 and word end is 4 (see case 3)
but if cursor is at position 5 (for the same word) and asked for word start and end, word start is 0 and word end is 5 (see case 1 & case 2)
based on this behavior I expected the word start to be 5 because we are on position after the word end which is 4, so word start & end needs to be 5.

Removing unnecessary variable