Marius, Thank you for the response. Answers to your questions follow. On Mon, Nov 21, 2011 at 12:06 AM, Marius Dumitru Florea <[email protected]> wrote:
Hi Aaron,
On Fri, Nov 18, 2011 at 11:37 PM, Ashtar Communications <[email protected]> wrote:
Hi,
I am having difficulty locating the source of an error where the contents of a TextArea property for a custom class object on a page ends up rendering in a WYSIWYG box as wiki syntax (as in, displaying the actual code in one long paragraph). "Corrupt" is probably not the right word for this, as I'm sure it's something I'm doing wrong...
Simple explanation: 1) User clicks a button to add a new instance of a class to the page, which also enters the Inline Editing mode. User pastes content into a WYSIWYG editor and saves the page. After save, the TextArea property shows up correctly in view mode with $doc.display(), with headings, formatting, etc... 2) Something happens - I cannot yet reproduce it, but I'm sure the user is doing something. 3) The object starts displaying the property as a single block of text with embedded wiki syntax, mostly what looks like custom parameters containing the formatting info, such as:
(% class="MsoNoSpacing" %) (% class="tagChar" style="font-size: 12pt;" %)
Is this the text displayed in view mode or the value of the TextArea property as seen when editing the page with the Object editor? I'd like to know the value from the Object editor.
It is both. In view mode, $doc.display() returns one long paragraph of text with wiki syntax embedded but no line breaks. Viewing the object in the object editor, the box renders the WYSIWYG data as a plain text box with the same long paragraph - but with a large number of ~ escape characters which do not appear in view mode. For objects which are not "corrupted" the WYSIWYG data appears in the object editor as wiki syntax with parameters, but with no escape characters and embedded line breaks - these objects look fine when in view mode.
etc... Even in inline edit mode, the contents of the WYSIWYG box have been replaced with this block of code, which does not appear with the actual formatting - just the raw code.
Looking into the page history, there is a version of the page saved right before the property becomes "corrupt." So something must be happening to trigger the conversion of the TextArea content into wiki syntax, which then gets saved over the original data.
The pages the user is using have multiple objects of the same class, all displaying their TextArea properties in a table. The majority of the time, it displays perfectly. This only applies to some objects on the page - though sometimes all objects on a page will simultaneously exhibit this behavior.
The pages also contain buttons to create a new object, as well as a button to delete each object individually.
I have one reliable method of producing this error. I used to have the "delete this object" button display while in Inline Edit mode - clicking it while in that mode would cause to entry to "convert." I
How can the deleted object become corrupted? I suppose you are referring to the other objects of the same type from the same page. Which one gets corrupted? All? Always all?
When in Inline mode, clicking on the delete button fails to delete the object. Instead, it just returns me to view mode with the object still present. Clicking on the delete button in view mode will successfully delete the object, however. I have seen all the objects on the page become corrupted simultaneously, but it is not always all. On some pages, there are several dozen objects, but only 1 or 2 will be corrupted at a time.
suppressed the button from displaying unless in view mode, which removed this cause of the error - but there is still some other mechanism for generating the same behavior.
Here's an example of the delete button code which I can use to cause similar behavior:
#set($delurl = "/xwiki/wiki/$doc.getWiki()/objectremove/$doc.getSpace()/$doc.getName()?classname=Sandbox.TestClass&classid=$obj.getNumber()&xredirect=$doc.getURL()")
Unrelated to your problem, you should never build the URL manually. Use instead $doc.getURL($actionName, $queryString).
Thank you, this is good to know.
<input type="image" onclick="location.href='$delurl'" value="Delete" title="Delete" style="float:right;" src="/xwiki/resources/icons/silk/cross.gif" />
Any ideas on what's happening?
What do you mean when you say that the "entry" is "converted" when you click on the delete button. AFAICS the delete button doesn't submit the inline form (so any changes will be lost) and it redirects to view mode after the object is deleted. Are you saying that the TextArea properties are corrupted as soon as you end up in view mode after the object has been removed? If so, then you should see in the history that the revision that deleted the object also modified the TextArea properties. I doubt it.
Are you using the browser back button or the edit menu to go back to inline edit mode after deleting an object? I'm pretty sure you are using the back button in order to not loose unsaved changes made before clicking the delete object button. If so, then you could be experiencing http://jira.xwiki.org/browse/XWIKI-7028 .
I mean that when I am in inline mode and press the delete button, I am sent back to view mode, but the object is not deleted. Instead, the contents of the object now appear “corrupted” in both view and editing modes. Sometimes, it seems that objects other than the one I tried to delete are also corrupted. Once I am returned to view mode, I am using the edit menu to return to inline mode – but the contents of the TextArea are corrupted immediately, regardless of which mode I am in. When I compare the page history between the version where everything was fine and the next version, where entries are corrupt, it shows the “New Value” in green text as a single block of text, and below that, the red strike-through text for “Previous Value” – both New and Previous have the entire contents of the TextArea – but the “previous” value contains line breaks and doesn’t have ~ escape characters. The revision is not tied to the deletion of an object – it is occurring even for revisions where no object was being deleted and other changes were being made. For example, I have examples of pages where a new object was added, text was pasted into the WYSIWYG editor and the changes saved, and the version history records both the addition of a new object, and “corrupt” changes made to other objects on the page without the user doing anything with those objects. I am now having some difficulty reproducing this error on demand, even with the delete button. Since the delete button has been removed from the inline view, it is also not the sole cause of the objects becoming corrupted. That is, users are continuing to report objects corrupted seemingly at random, despite the absence of a delete button. I do not think I am experiencing the same bug as the link you gave. I can reproduce that one (#7028). Using chrome, if I view the page, go to inline mode, save and view, then click back in the browser, it returns to inline mode, and the contents of all the WYSIWYG TextArea’s render as a block of HTML code. However, the bug I am seeing is different – instead of HTML code, the TextAreas are rendering as a block with wiki syntax. I’m also pretty sure that I am not using the back button, and still seeing the contents of the TextArea being replaced. This appears very similar but still different in some way from #7028. Something else that may help shed light on the problem. On pages where corruption is a problem, I am periodically receiving errors similar to the following when attempting to save the page:Sandbox.TestClass_2_TextArea: Exception while parsing HTML The page then refuses to save changes and stays in Inline mode. I have seen several JIRA listings for similar bugs, but they all appear slightly different. As far as I can tell, the TextAreas do not contain embedded links, and several of the JIRA bugs are listed as fixed. Could this be related to the content of the data being pasted into the TextArea? It is coming directly from Word, and contains URL’s, though none of it is in wiki syntax. For example, I just tried the following (using Chrome, though I have seen similar behavior in FF): 1) Page has 4 objects, each with a WYSIWYG TextArea, all displaying correctly.2) Select “Inline” from the Edit menu3) Immediately click “Save and View” – this throws the above exception in red at the bottom of the page. The contents of the objects on the page now display in the wysiwyg editor in inline mode as “corrupt”4) Click “Cancel” – this returns me to view mode, everything is normal.5) Close browser. Reopen – repeat, this time, nothing happens. No error, no corruption – despite going through the exact same steps. The exception does not appear to be thrown on a consistent basis – I have had users edit a page on one computer and receive an error, leaving them unable to save the page. I then opened the page on a separate machine, and successfully edited and saved the page with no error. Baffled, aaron