Etherpad-lite: Authorship of bullet points changes when a second author edits them

Created on 27 Mar 2018 · 12Comments · Source: ether/etherpad-lite

This has been recreated in both in our internal version of etherpad and on beta.etherpad.org (https://beta.etherpad.org/p/tapril_test).

When one author adds content to a bulleted list of items, the authorship correctly indicates the author. Once a second author modifies the bullet point, the authorship of the full bullet point changes to the second author and when using the hover author plugin, the author name shows as "[ojbect object]".

I do not recall this being an issue on 1.5.1 or before but I have not had a chance to go and do a binary search on the versions to figure out where the bug was introduced.

Black hole bug Bug

Source

timapril

👍1

Most helpful comment

Ok, after a (long) while, I was able to find a way to handle all the scenarios, and this issue is finally fixed.

lpagliari on 9 Jul 2018

🎉3

All 12 comments

I'm pretty sure this is a duplicate no?

JohnMcLear on 3 Apr 2018

@JohnMcLear I have just re-read the list of open issues and I cant find anything that makes me think this is a duplicate issue. I also looked more closely at the results for searching for "color" and "author" with no luck finding a dup.

timapril on 3 Apr 2018

@lpagliari, this is frustrating many of my colleagues. Do you have any updates?

benlind on 6 Jun 2018

👍1

sorry, guys, I didn't have time to focus on Etherpad lately. I'll try to take a look on the next few days

lpagliari on 8 Jun 2018

I could reproduce the first issue (line author is fully changed), but not the second one (_author name shows as "[ojbect object]"_). I'm still investigating the causes...

lpagliari on 11 Jun 2018

Hi @lpagliari, Have you had a chance to look at the line author issue? We could really use a fix for this even if you haven't had a chance to look at the second issue.

dgoldfein on 25 Jun 2018

@dgoldfein yes, I've been investigating the issue for the past couple of weekends. I still don't have a fix for it, but at least I found the commit that broke the behaviour. I'm looking on how to fix that now.

lpagliari on 2 Jul 2018

👍2

Ok, after a (long) while, I was able to find a way to handle all the scenarios, and this issue is finally fixed.

lpagliari on 9 Jul 2018

🎉3

@lpagliari, Thanks for fixing this! We tested the dev code in our test environment and the fixes worked. Can't wait for the next official release!

dgoldfein on 10 Jul 2018

@lpagliari Any change of getting this rolled into an official release? Who should I contact about that?

dgoldfein on 23 Jul 2018

I guess @muxator might help us here... Any plans for a new release, @muxator?

lpagliari on 24 Jul 2018

My main concern is #3268: it fixes a bug, but breaks plugins.
If this change had a clear test case (see #3425) we could accept the breakage, provided we bump version number to 1.7 (milestone) and have a clear communication plan.

If I had to cut a release right now, I would: