Richtext field getting/saving content from other objects?

Plone Support
1

I've been battling with a bug report that is scary, unpredictable and so far unreproduceable on my development builds.

Users are reporting that they have filled out a rich text field (using the richtext field from plone.richtext behavior) and when they save and view the object, the field shows content from a completely different object, typically saved that day or the previous day.

I even had a report today that on "Add new" that the text field was pre-populated with text from a different object which is incredibly suspicious.

We have a content type called a "Story" and we create many every day.

So far, the reports are:
"I have x stories open in x tabs that I compose in the morning, save, and open back in edit mode.
Then I wait for the audio clip (file) to arrive, which I then attach to the story, save, and publish.
On save, the body field (rich text field) changes to the text I put in a different story."

"I composed my story, saved, and the body text was not what I typed. It's from an older story"

"I open a story in edit mode and the story body is some other story's text"

"I went to create a new story and the story text field was already filled out with another story's text"
(I don't believe this one - the screenshot I got was of an edit page)

This is reported from both chrome and firefox, so I don't think it's a browser bug.
I'm wondering if there is something in the PortalTransforms cache. We have implemented some transforms, but we don't mess with the caching at all.

Does anyone have any debugging tips or ideas or anything? I'm pretty lost when I can't even reproduce the issue myself.

2

Just now had another interesting report come in.

Story text changed when he added an image to the story, before saving it.
And he was using Firefox, and he logged in using Chrome to see the same
story, the text was correct.

So, java scripts massing it up it seems.

3

If client site interesting things happen in text area's and you are sure you haven't seen before and nothing related has been changed server side: ask users if they want to disable all their browser extensions for a while and see if the issue persists.

There have been some very 'cool' browser extensions around under the guise of productivity tools that mess around with browsers' textarea's.

1 Like
4

Wild guess, but is it possible that this has something to do with plone.app.drafts? I have a vague memory I saw something similar 'ages ago'.

5

Yes, indeed it does have something to do with plone.app.drafts.

Yesterday, I was lucky enough to re-create it in my dev environment. I still don't know how to get it into the bugged state, but I did observe the effects.

I brought one of my objects up under edit mode, and noticed that the html source had the wrong value for the textfield - at that point I know it's coming directly from plone, and not some ajax tomfoolery.
Let's call this object /RFA/english/news/story3.html

Opening this path in default view shows the correct text.
Opening the path in a different browser in edit mode shows the correct text.

Inspecting the cookies I saw that I had plone.app.drafts cookies. Deleting these cookies resolved the issue, and restoring them replicated the issue.

The cookies:

plone.app.drafts.targetKey="fac6a312be9146688a0e5e9e2fc20752"; 
plone.app.drafts.draftName="draft"; 
plone.app.drafts.userId="admin"; 
plone.app.drafts.path="/RFA/english/news";

Note that the path is to the parent folder, and all these cookies have a 'cookie path' to the same. There is no cookie for /RFA/english/news/story3.html

This was retirieving the text field value from a draft of /RFA/english/news/story2.html

I have not been able to get the cookies to get in this state again, but it's definitely the cause.
More research needed. Hints are appreciated.

6

I have steps to recreate it now. Wow.

Navigate to a folderish (call it '/folder')
Create two Documents, fill them out and save them. (any portal type will do, but stay consistent)
Clear all your plone.app.draft cookies
Visit the zmi and clear all the drafts.

You are now 'clean'

Go back to '/folder' and Add New->Document (can be whatever, but needs to be consistently the same portal type for best results)
You now have a bad draft cookie set to the path /folder
Leave that add new form open in a tab. Forget about it You might want to add a few field values to the add form to make @@z3cform_validate_field fire and set some more (correct) draft cookies (path is /folder/++add++document)

Open a new tab and edit an existing Document in /folder - let's call it 'document 1'
This edit will send the bad draft cookie in the request.
plone now has all the fields of 'document 1' saved under the bad draft cookie

Open yet another tab and edit a different document in /folder - let's call it 'document 2'
again, the edit will send the bad draft cookie in the request.
But this time, plone app drafts sees the cookie and honors it, creating a draft proxy with document 1's draft and document 2 context.

Viola! Document 2 edit form with Document 1's form data.

Go back to that Add form from the first step and 'cancel' it.
bad draft cookie is deleted from the client. (note that the ++add++Document cookie remains, tho)

refresh the edit view for document 2 and viola, field values return to normal.

Basically, a draft cookie for the path http://myhost.com/myfolder is mistakenly created during Add.
I believe that's the source of the bug.

Then any document http://myhost.com/myfolder/mydocument will start using that draft cookie as it's unique cookie.

If this bad draft cookie who's path is a folder is never set on the client, then the correct behavior - setting a draft cookie for /myfolder/mydocument with it's own unique ID happens.

Can someone try to re-create before I file a bug against plone.app.drafts ?

Thank you in advance, and I'm sorry I'm a bug finder. Plone is actually really great and I hope that I don't come across as disliking Plone. We just seem to use the crap out of it and have enough users that the edge cases start popping up.

7

Which Plone version are we talking about?

Did you install/add plone.app.drafts 'on purpose' yourself because you
need it for customisation, or did it get pulled in as a dependency from some other addon? I've only seen plone.app.drafts being pulled in as part of tiles management, so mosaic and collective.cover.

We have used those add'ons in multiple projects but until now I have never seen that plone.app.drafts also hooks into 'full page' edit forms of 'default' content types, it is used to manage/save form submission/state on forms in modals like when dealing with tile edits.

8

Good questions. They helped.

I'm on 5.2 Py3 with Mosaic. Mosaic pulled in plone.app.drafts.
p.a.drafts also provides the "IDraftable" behavior.

What probably happened: While building our new dexterity content types for plone 5 I enabled drafting support directly from the Dexterity behaviors UI (confusing it with versioning support), exported the types profile, and that's how it got into our 'Story' portal_type's behaviors in production.

I was incorrect in thinking that the drafting support behavior is enabled by default in p.a.contenttypes.

You are correct - full page edit forms for default content types do not provide draft support,
unless you enable the behavior, which I did.

This is good news, because it makes me more confident in simply removing the drafting behavior to solve the issue. I don't think our users really relied on it.