elm_code: Right click paste doubles on every other paste.

[NuLogicSystems]

Title says it all. Right click paste actually does a double paste every other time.
What is expected: -alpha1
What you get the second time: -alpha1-alpha1
and back to what is expected the third time, and so on.

This does not happen when using paste from the bar.

[wltjr]

Nice catch, seems to be ecrire specific I could not replicate in elm code tests or EDI. Not sure offhand what could be causing this, as I do not believe I have any code for such. Maybe something legacy from elm entry from before the switch to elm_code. Seems to be on the even pastes, not odd. If I continue to paste, every other is duplicated.

[wltjr]

I think this is a bug in elm code though I cannot replicate it in anything else. It is strange, as it only fires with right click paste. It does not via CTRL-V or as you stated via paste button in toolbar. Those are the only two I coded, the right click is function I did not code nor have any hooks. Thus thinking its a elm code issue.

[wltjr]

Opened upstream task T5651

[wltjr]

This seems to be fixed with EFL 1.20.1. Can you confirm?

[NuLogicSystems]

Yes, I can confirm.

[NuLogicSystems]

This seems to be back in efl-git, I haven't tried efl 1.20.4 yet..

[wltjr]

I am running 1.20.4 and have not seen it. Really not to pleased with the elm_code situation. Waiting on a number of upstream issues and had more drama over words....

They disabled my phabricator account so I cannot do anyting. I may stop with EFL stuff entirely. Seems a total waste of time....

[NuLogicSystems]

Aww. Well that would suck, I rather enjoy ecrire now..

[wltjr]

I was just starting to do more work on it. I added main menu bar and option to remove that and/or toolbar for a more slimmed down desktop look. It has a few issues. Like you can remove both, but need warnings. Presently have to edit or delete config file to restore. I had plans to do more work today but got bogged down in stupid waste of time on a few tasks I opened in phabricator. None of which I can work now or respond to, etc. I just worked on other stuff...

[wltjr]

Also some weird issue with writing boolean integers to config file via eet. Seems to cause it to not start at times and I have to delete the config file. Seems storing booleans is difficult. Guess I can revert to regular integers. or maybe that is the problem. Not sure, but not surprised. Stuff is very strange, and poorly documented. Like nothing on how you write a boolean to a cfg file... Not eet data type for such. Thus I guess they are using integers and converting between Eina_Bool, which seems to work just the same in if statements as using 0 and 1. Thus it seems like it should store a 1 or 0 to file. Instead its storing other stuff. So bit buggy, nothing new.... :(

[wltjr]

Going to have to look further into this. I can replicate this in ecrire but not in edi or elm_code tests. Which is strange. Ecrire does nothing with the right click paste stuff, but maybe something else is interfering with that. It maybe ecrire specific. Just very minimal code for such. Maybe has to do with the copy and paste stuff from outside of ecrire I added. That maybe adding the 2nd copy of the past somehow. Either way I will look further into this.

[wltjr]

Sadly definitely upstream and can only replicate in ecrire... There is very minimal code for such. Basically just a single callback for the buttons in main menu or toolbar to call. it does not fire otherwise. It is very strange as this does not happen with CTRL-V, nor using the past buttons. Its just right click and the 2nd paste doubles every time. Not sure why edi or elm_tests do not have the same issue.

Not sure if this was ever addressed as I am on EFL 1.20.4. Unless it was fixed in git and then reverted not sure. Either way seem powerless to correct sadly.

I added some temp debug code so I could see when its fired.

static void
_paste(void *data, Evas_Object *obj EINA_UNUSED, void *event_info EINA_UNUSED)
{
   fprintf(stdout,"\n\n\n\n\n\n\n\nPaste callback fired\n\n\n\n\n\n\n\n\n\n");
   Ecrire_Doc *doc = data;
      elm_code_widget_selection_paste(doc->widget);
}

[NuLogicSystems]

Take your time, I can always use the toolbar buttons. ;)
Note: I haven't seen this happen in a couple of days, but then I update efl-git almost daily on my machine. I'll keep testing as time goes on.

[wltjr]

Its going to have to take time, till elm_code devs feel like taking a look. Which likely means they will have to test it out in ecrire as it does not seem to occur in other. Really wish it was something I could address directly. Like the 3rd button copy and paste. I may have to start patching EFL. Which any patches would not make to upstream, so would have to be applied outside...

You can also use CTRL-V. that and the buttons do not cause it to duplicate.

The elm_code right click is unique. If you go to any of the Entries in elm tests. Right click in there. You get a different right click menu. It has a title Text, and different drop down menu. Like in a regular entry I get Text -> Paste. But in elm_code stuff I get Cancel or Paste. If the buffer has paste, it shows Paste, otherwise Cancel. but not Text -> Paste, etc like in entries. I will see if I can find what is taking place in elm_code. Though even if I find issue not sure what all I can do there....

[wltjr]

I found the cause! It only happens when text is copied from outside ecrire. If you copy/paste from within it does not ever duplicate. That said it seems it is still a bug in elm_code. Not to hard to follow but a couple steps.

First I add a focused callback listener on the window

   evas_object_smart_callback_add(main_doc->win,
                                  "focused",
                                  (Evas_Smart_Cb)_get_clipboard_cb,
                                  main_doc);

Which fires this callback, that fires another callback to activate/deactivate the copy/paste buttons on toolbar. Presently not deactivating main menu items but I may not sure. Most apps do not so maybe over kill. May not have been necessary on toolbar buttons but that is done.

static Eina_Bool
_get_clipboard_cb(void *data,
                  Evas_Object *obj EINA_UNUSED,
                  void *ev EINA_UNUSED)
{
  Ecrire_Doc *doc = data;

  elm_cnp_selection_get(doc->win,
                        ELM_SEL_TYPE_CLIPBOARD,
                        ELM_SEL_FORMAT_TARGETS,
                        _activate_paste_cb,
                        doc);

  return EINA_TRUE;
}

It is that call to elm_cnp_selection_get that causes the issue, but still should not occur. Since it only doubles every other, rather than all the time. This is still not adding or doing anything with the paste buffer. Nor adding it to the document. So that is sitll coming from elm_code.

But if I comment out elm_cnp_selection_get, the duplicate paste stops. With it there, it seems to be the cause of the duplicate paste. Still an elm_code bug as it handles the adding paste buffer to the document. It also does not occur ever with CTRL-V or the paste button. Which further makes it right click specific. Only right click paste duplicates on 2nd paste, not CTRL-V and not paste button.

Its a combo of elm_cnp_selection_get and right click paste that causes the duplicate. At least the trigger is known now. But no clue on a solution and likely has to be fixed in elm_code. Which I cannot file any bugs on, phabricator account deactivated. Because I am an abrasive racist bigot who lacks social skills and minimal level of decent human behaviour not fit for the EFL or E community....1

[wltjr]

Adding upstream so they are aware of issues
@Enlightenment @ajwillia-ms @zmike

[andydotxyz]

Please provide steps to replicate in elementary_test -> Code Editor.
The code snippet above illustrates a second call to elm_cnp_selection_get so a duplicate would not be surprising.

[NuLogicSystems]

I can't reproduce this in code editor, but it does still happen in ecrire.

[wltjr]

@ajwillia-ms see code in previous comment

It is strange, it could be ecrire specific. But seems to only occur when using that code block. Which I do not think should cause it to double. I think I saw this happen once in Terminology as well. It maybe something in EFL and no elm_code specific. That is a for sure trigger for ecrire to replicate.

[wltjr]

FYI _activate_paste_cb does not do anything other than activate a button. It does not handle any pasting. Unless activating the button causes it to fire. Which would be odd. I cannot understand why a call to elm_cnp_selection_get would duplicate the paste but that seems to be what causes it to happen. If I comment that out, the double pasting stops.

[andydotxyz]

Might it be worth using the elm_code_widget_selection_* APIs instead? The Elm cnp APIs can be confusing. Pretty sure this does not qualify for upstream_bug.

[wltjr]

elm_code_widget_selection is in use. This is used for other things. What this code does is activate the paste button when ecire gets focus if something was copied, added to paste from outside of ecrire. Otherwise button would be active all the time, and when pressed would do nothing when paste buffer was empty.

1. Open some app copy text.
2. Go into ecrire, ecrire gets focus
3. Paste button is activated because the buffer has paste data
4. Press button to paste data, if not active no paste data.

This was part of fixing Ecrire for wayland very early on. Some of the first code I took over given raster went off and commented code of ecrire in git.e.org. Which sparked a mailing list controversy. As he was reluctant to touch other code bases. Despite having me ask Tom to take over ecrire and all that jazz...

None the less it is needed, and I did not see anything in elm_code that would do such. elm_code is not aware of there is paste data in the buffer. That is an elm_cnp operation. Which I am fairly familiar with as I moved clipboard over to elm_cnp as well.

[andydotxyz]

Well, the issue is that elm_cnp_selection_get is not a passive operation, it does not seem to have been designed to check for buffer availability. By calling that you are initiate a selection paste.
I would guess that you are not using the data and it somehow gets appended in memory the next time the widget tries to paste and so there is twice the content.

[wltjr]

Which sounds like an elm_cnp bug. Which elm_cnp is new and meant as a layer between X and Wayland. Despite the fact it has little to no Wayland code. I am not sure Wayland even supports copy and paste.

Keep in mind it does not duplicate all the time. it does it every other paste. it is for sure a bug. Just maybe in elm_cnp vs elm_code. Just only able to replicate in elm_code. Though I think this happened to me yesterday in terminology. I know output was doubled for sure, as I was re-installing packages, and I saw the list duplicated.

[NuLogicSystems]

This is definitely a double past, hitting undo once removed just the duplicate.

[wltjr]

Not sure how to address, need to file bug with upstream on handling of

  elm_cnp_selection_get(doc->win,
                        ELM_SEL_TYPE_CLIPBOARD,
                        ELM_SEL_FORMAT_TARGETS,
                        _activate_paste_cb,
                        doc);

Seems like there is a bug there and/or with that + elm_code. Though that it does it every other time vs consistently think is a pretty clear sign of a bug. I guess the above check for clipboard grabs contents as well and causes something to happen there, half the time. There is no check to see if the clipboard has contents, which is essentially what I am doing. Thus maybe needs new code, a new function to call like

elm_cnp_selection_has
or
elm_cnp_has_selection

Think most should get the idea. Some function to check if there is contents, vs one that fetches the contents. Still that I am not using the fetched contents, should not matter. For some reason that causes it to double up half the time. Which seems like some conditional is being toggled, and where ever that conditional is, likely is where the bug resides. It should not toggle, and no duplicate paste. Like it does not half the time.

Must be some boolean switching to cause it to happen half the time. :)

[wltjr]

Still present in 1.20.7-pre. Seems like this will exist til elm_cnp is furthered to support a buffer check operation.

[wltjr]

This is fixed in 1.21-beta1, however there is a new right click paste issue. If you right click and paste, you cannot type until elm_code loses and regains focus. Clicking else where or outside the window makes it such you can type again. May need to open a new issue and close this one once EFL 1.21 is released, unless that is also fixed.

[NuLogicSystems]

I couldn't compile EFL 1.20-beta 1, thus I gave up.
I'll test this once EFL 1.21 hit's final (released).
Until then, I'm good.
I can always hit undo when doubles up.

[wltjr]

Why could you not compile 1.21-beta1? Alpha was missing a file, but beta seems ok. Either way seems both issues are resolved in git, so when ever 1.21 is released.

[NuLogicSystems]

Yes, alpha 1 was missing a file, however even after pulling the tarball from git, it would lock up during compile, so I just gave up. Besides, this would only benefit me since I don't distribute pre-release packages in my repository any longer. Well, at least not ones that actually have a release. ;)

[wltjr]

Interesting, wonder if it is the combo of options being used. I have built it a few times with no issues. Have you tried directly from git? Maybe some issue in the beta release. Hopefully not something that ends up in the final release. Have you opened an task in phab? If not and still exists in git I would. Either way something I hope I do not experience, but good to be aware of in case I do, thanks for mentioning!

[NuLogicSystems]

No, I only tried the alpha, and the issue was doxygen.
I just didn't care enough to run the build again without compiling the docs.
AKA it's not important enough to fiddle with since a alpha, beta or rc, would never make it to my repository anyway .;)

[wltjr]

Well just so it does not end up in final release. I believe Bryce Harrington has been working on the docs, per this post in mailing list. May want to bring it to his attention. I never build the docs, so have not run into that. I guess I could test it out with that enabled. I only deal with alpha, beta, rc stuff if I am concerned with the final outcome like EFL, etc. For other things like Jetty, or that I use minimally I wait till a release. EFL seems to need all the testing before any release. Tends to be issues around releases, I have run into many both before and after.

[NuLogicSystems]

Agreed, and I do appreciate beta testers as much as the next guy.
It's just that I don't have the interest to be one anymore.
Well, at least not like I once used to. ;)

[wltjr]

Tested in released EFL 1.21.0. I could not replicate the original issue. No duplicate pastes from right click. Seems resolved, closing.