broken copy & paste
Closed, ResolvedPublic

Description

  1. Launch Enventor.
  2. Ctrl + A to select all
  3. Ctrl + C to copy it.
  4. Ctrl +V to paste it (hold pressing ctrl + v) to paste continously.
  5. You could find some broken text were inserted while pasting.
Hermet created this task.Feb 2 2016, 7:08 PM
Hermet updated the task description. (Show Details)
Hermet raised the priority of this task from to Showstopper Issues.
Hermet claimed this task.
Hermet added a project: Enventor.
Hermet moved this task from Action Items to 0.8.0 on the Enventor board.
Hermet added subscribers: Hermet, NikaWhite, Jaehyun_Cho, herb.
Hermet renamed this task from Enventor v0.8 - broken copy & paste to Enventor v0.9 - broken copy & paste.Feb 28 2016, 8:32 PM
Hermet reassigned this task from Hermet to NikaWhite.
Hermet updated the task description. (Show Details)
NikaWhite moved this task from 0.8.0 to 0.9.0 on the Enventor board.Mar 1 2016, 5:12 PM
Hermet moved this task from 0.9.0 to Action Items on the Enventor board.Mar 4 2016, 4:57 AM
Hermet renamed this task from Enventor v0.9 - broken copy & paste to broken copy & paste.
Hermet moved this task from Action Items to 0.9.0 on the Enventor board.Mar 4 2016, 5:42 AM
Hermet moved this task from 0.9.0 to 0.8.0 on the Enventor board.Mar 4 2016, 5:56 AM
Hermet moved this task from 0.8.0 to 0.9.0 on the Enventor board.Mar 6 2016, 8:33 PM

Finally I investigated this defect more closely,
I found, that something similar happens in the entry as a widget. Uninterrupted pasting text from a buffer sometimes cause inserting pair of symbol "F#".
For check this you can try to inserting blocks of text into Ecrire. I used texts block, that contain 7 lines with 45 characters in each line. After uninterrupted inserting around 2000 times, the symbol pair "F#" is inserted into text.
In case of Enventor the symbols "F#" are deleted by autointendation module. If autointendation disabled will happens the same as in Ecrire.

I think we should involve @herdsman or someone, who is familiar with entry widget.
Also we should to discuss this user case. On my opinion this situtaion is unusual in daily using, One of possible ways is abandon ability to uninterrupte paste. Only the one paste action in one time when hot-keys combination is pressed.

Hi thanks for adding me.
Are you able to reproduce this with "elementary_test -to Entry"?

herdsman lowered the priority of this task from Showstopper Issues to Normal.Mar 23 2016, 4:57 AM

Nevermind, seeing it. I'll investigate.

Hi!
Actually impossible to reproduce in the elementary_test -to Entry, because this entry resized accordingly to the pasted text. But in Entry scrolled it reproduced.
For example, I paste next text by pressing Ctrl+v hotkey around 10-20 seconds :

/usr/lib/libeina.so.1	 0x7f3e07be1d06 0x7f3e07bbf000
/usr/lib/libeina.so.1	 0x7f3e07be2abb 0x7f3e07bbf000
/usr/lib/libeina.so.1	 0x7f3e07be3a1a 0x7f3e07bbf000
/usr/lib/ecore/system/upower/v-1.17/module.so	 0x7f3dfb604703 0x7f3dfb603000
/usr/lib/libeldbus.so.1	 0x7f3e0485a8ee 0x7f3e04845000
/usr/lib/libdbus-1.so.3	 0x7f3e04607392 0x7f3e045f4000
/usr/lib/libdbus-1.so.3	 0x7f3e0460adb1 0x7f3e045f4000
/usr/lib/libeldbus.so.1	 0x7f3e04854e78 0x7f3e04845000
/usr/lib/libecore.so.1	 0x7f3e086bb4b0 0x7f3e086a8000
/usr/lib/libecore.so.1	 0x7f3e086bd1c9 0x7f3e086a8000
/usr/lib/libecore.so.1	 0x7f3e086bd6fc 0x7f3e086a8000
/usr/lib/libecore.so.1	 0x7f3e086bdc17 0x7f3e086a8000
/usr/bin/elementary_test	 0x55e167258b61 0x55e167238000
/usr/bin/elementary_test	 0x55e16725666c 0x55e167238000
/usr/lib/libc.so.6	 0x7f3e0731c710 0x7f3e072fc000
/usr/bin/elementary_test	 0x55e1672566a9 0x55e167238000

and after a some time of uninterraptable pasting saw next text:

LL/usr/lib/libeina.so.1	 0x7f3e07be1d06 0x7f3e07bbf000
/usr/lib/libeina.so.1	 0x7f3e07be2abb 0x7f3e07bbf000
/usr/lib/libeina.so.1	 0x7f3e07be3a1a 0x7f3e07bbf000
/usr/lib/ecore/system/upower/v-1.17/module.so	 0x7f3dfb604703 0x7f3dfb603000
/usr/lib/libeldbus.so.1	 0x7f3e0485a8ee 0x7f3e04845000
/usr/lib/libdbus-1.so.3	 0x7f3e04607392 0x7f3e045f4000
/usr/lib/libdbus-1.so.3	 0x7f3e0460adb1 0x7f3e045f4000
/usr/lib/libeldbus.so.1	 0x7f3e04854e78 0x7f3e04845000
/usr/lib/libecore.so.1	 0x7f3e086bb4b0 0x7f3e086a8000
/usr/lib/libecore.so.1	 0x7f3e086bd1c9 0x7f3e086a8000
/usr/lib/libecore.so.1	 0x7f3e086bd6fc 0x7f3e086a8000
/usr/lib/libecore.so.1	 0x7f3e086bdc17 0x7f3e086a8000
/usr/bin/elementary_test	 0x55e167258b61 0x55e167238000
/usr/bin/elementary_test	 0x55e16725666c 0x55e167238000
/usr/lib/libc.so.6	 0x7f3e0731c710 0x7f3e072fc000
/usr/bin/elementary_test	 0x55e1672566a9 0x55e167238000

The string LL contain non printable symbols after each L.

herdsman added subscribers: thiepha, JackDanielZ.EditedMar 23 2016, 5:32 AM

I see the data received by _x11_data_preparer_markup@elm_cnp.c _x11_selection_notify@elm_cnp.c is sometimes corrupted if you paste-spam.
Cnp guys, any thoughts?

EDIT: Oh right forgot to mention - if I slow my process (e.g. via valgrind) this is way easier to reproduce.

Hi guys,

I strongly think it is related to cnp itself and not entry. The problem is that the Copy&Paste process should be synchronous but the current implementation doesn't prevent async behavior (as X11).
When a paste is required, a few packets are transferred between the application and X11, such as:

  • Give me the supported types of the data, followed by the response with the types (UTF, plain, image...)
  • Send me the data with this specific type, followed by the data

When the data arrives, the callback is invoked and the entry/whatever can display it.

If many requests are done in parallel, like in this scenario, even if packets are short, I think inconsistency can happen. I already saw this issue when I worked on big data that are received in many chunks (was happening really fast).

The solution is to stack the requests and treats them one by one. There is an old patch that has never been pushed (https://git.enlightenment.org/core/elementary.git/commit/?h=devs/jackdanielz/blocking_cnp&id=cc9447bcc671131fb7a28b90d5fe6faada0ee790).
I got to check it to see if it fixes the issue.

JackDanielZ

Hermet reassigned this task from JackDanielZ to thiepha.Mar 24 2016, 12:35 AM
Hermet raised the priority of this task from Normal to Showstopper Issues.
Hermet reassigned this task from thiepha to JackDanielZ.Mar 24 2016, 12:37 AM
herdsman lowered the priority of this task from Showstopper Issues to Normal.Mar 24 2016, 12:52 AM
Hermet moved this task from 0.9.0 to 1.0.0 on the Enventor board.May 18 2016, 7:55 AM
Jaehyun_Cho raised the priority of this task from Normal to Showstopper Issues.Jun 9 2016, 11:09 PM

ping?

@JackDanielZ explained it.
Unfortunately, we have no one with spare time to add the code that synchronizes the INCR data.

raster lowered the priority of this task from Showstopper Issues to Normal.Jul 28 2016, 7:07 PM
Hermet closed this task as Resolved.Aug 3 2016, 2:56 AM