Summary:
Anchor and item tags should be updated when text is changed.
In _edje_entry_imf_event_delete_surrounding_cb function,
the text is changed by "evas_textblock_cursor_range_delete" API
and there was no update about anchor and item tags.
It can result that the tags hang in the air after deleting.
Reviewers: tasn, woohyun, seoz, jihoon
Reviewed By: tasn
CC: cedric
Differential Revision: https://phab.enlightenment.org/D368
parsing problem with opengl_strtok() which would free the previous
token "p", but in some cases it would be a const string. this should
fix CID 1039653
in one case data is not separately allocated but is part of the
Eet_Variant_Unknow struct where it is allocated as extra space on the
end of the data blob. in this case don't free it, otherwise do (pass
in true) as before. this should fix CID 1039728
this fixes CID 1039884 which isn't a real problem as the callback del
never dereferences the data pointer - just uses it as a value, but
this is really to ensure that it doesn't come back if the code were to
change.
size_ret is used later as an argument for malloc, so it should be
positive. In addition this should ensure that
ecore_x_window_porp_property_get returns a positive value and is true if
we malloc data.
Hopefully also fixes CID 1135636
stable release - cherry-pick me!
the evas gif loader used way too much cpu to decode animated gifs
because in the rewrite that made it correct, it did not store the
current gif file handle and state, thus each frame it would have to
decode all frames before that one before finally decoding the final
one. that means to decode frame 200, it decoded frame 1, 2, 3, 4 etc.
all the way up to 199 THEN decoded 200 on top, so decode cost became
progressively more then further through the animation you were.
this fixes that by storing state and file handle and allowing you to
iterate through.
Markup parsing will segv if a value string is empty,
as in "<style=>". Sure, this is invalid, but hey, it could
definitely be used from an app or even by a user writing
his own markups :)
The internal doc says this function expects an item to be
of the form "key=val" but there are no checks beyond the
presence of "=" in the string before calling it.
There's no need to call it on text_input_leave too, otherwise this would
be called twice, the one from text_input_leave possibly being called
after the focus was regain already by a text input, causing the bug
described in T237.
This fixes T237.