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

User Input in WYSIWYG Editor is lost after conversion error

    Details

    • Tests:
      Integration
    • Difficulty:
      Medium
    • Documentation:
      N/A
    • Documentation in Release Notes:
      N/A
    • Similar issues:

      Description

      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.

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved:
                Date of First Response: