Uploaded image for project: 'XWiki Platform'
  1. XWiki Platform
  2. XWIKI-9750

User Input in WYSIWYG Editor is lost after conversion error


    • Tests:
    • Difficulty:
    • Documentation:
    • Documentation in Release Notes:
    • Similar issues:


      If a conversion error in the HTMLConverter happens while saving content
      from the HTMLEditor, the user is redirected to the editor and an error
      message is shown, as expected. However the latest edits to the content are lost.
      Instead the contents from the last successful save are shown, but in
      plain wiki syntax instead of html.

      What seems to happen:
      When the HTMLConverter - called from the DefaultXMLFilter - creates an error, the Filter stores the error and the user submitted data in two session variables "com.xpn.xwiki.wysiwyg.server.converter.errors" and
      "com.xpn.xwiki.wysiwyg.server.converter.output" respectively.

      The content then should be redisplayed from the information stored in the session in the wysiwyg editor, as it has
      happened in the macros.vm, #macro(wysiwyg_input ...)
      Hwoever this macro has been scrapped in commit
      753000ec27d4a0ca9259c3f63112536065ea841d and (as least so it seems to me) this functionality has never been restored elsewhere.

      The error rendering macro wysiwyg_displayConversionError properly discovers the error from the session, and beside of rendering an error message it also sets 'convertInput' to false, but as the input is not updated to the latest tried-to-save-as-html content, the currently saved wiki-syntax content is shown in raw wiki syntax.

      Steps to reproduce: hm, tricky.
      Unlike some of our users, I have a hard time producing any conversion
      errors via the wysiwyg editor. the only way I figured to force a conversion error is to remove a "startwiki:" marker from some comment around a wiki link (via Firebug). Afterwards pressing e.g. the "Preview" or "Save & View" button triggers the behaviour.




            • Assignee:
              mflorea Marius Dumitru Florea
              camil7 Clemens Robbenhaar
            • Votes:
              0 Vote for this issue
              2 Start watching this issue


              • Created:
                Date of First Response: