|
| Description: |
h2. Steps to reproduce
* Create a page whose content is a single Live Data macro call, for example:
{code}
{{liveData source="liveTable" sourceParameters="className=XWiki.XWikiUsers"/}}
{code}
* View the page: the table is rendered, as expected.
* Click *Edit* to enter the in-place WYSIWYG editor: the table is still rendered inside the editor.
* Click the *Source* button, then click it again to go back to WYSIWYG.
h2. Expected result
The Live Data is rendered in the editor again, as it was before switching to Source.
h2. Actual result
The macro is not rendered any more anymore . Its output in the editor stays the bare, empty element the
server sends back, {{ monospace}} <div class="liveData loading" data-config="..."/> {{/monospace }} with
no children, so nothing meaningful is displayed where the table was. The macro call itself is not
lost: it is still in the widget's {{ monospace}} data-macro {{/monospace }} attribute and the page saves
correctly.
Two things make this worse than a cosmetic glitch:
* The author has no way to tell the macro is still there. CKEditor reveals the
{{ monospace}} macro-placeholder {{/monospace }} ("macro:liveData") only when the widget has neither
width nor height ({{monospace}}ensureMacroWidgetVisible{{/monospace}} /
{{monospace}}isElementVisible{{/monospace}} in {{monospace}}xwiki-macro/plugin.js{{/monospace}}). The
empty Live Data element measures about 1066x16 px, so the widget counts as visible and the
placeholder stays hidden. The author sees a blank strip, and cannot click it to edit the macro
either. This is the situation described more generally in XWIKI-22046.
* The only thing that initialises initializes a Live Data is the
{{ monospace}} xwiki:dom:updated {{/monospace }} event
({{ monospace}} xwiki-platform-livedata-webjar .../src/main.js {{/monospace }}:
{{ monospace}} $(document).on("xwiki:dom:updated", init) {{/monospace }}, which calls
{{ monospace}} container.find(".liveData").liveData() {{/monospace }}). The macro widget does fire that
event from its {{ monospace}} init {{/monospace }}
({{ monospace}} xwiki-macro/plugin.js {{/monospace }}, guarded by
{{ monospace}} data-xwiki-dom-updated {{/monospace }}, added in CKEDITOR-328), and the element coming
back from the Source round trip is freshly rendered by the server and therefore does not carry that
flag - so on paper the event should fire again. Why the initialisation initialization nevertheless does not take
effect on this path has not been identified yet, so the cause above is a lead, not a diagnosis.
h2. Notes
* This is not specific to one macro: it reproduces with the plain
{{monospace}}liveData{{/monospace}} macro. It was noticed with the new
{{monospace}}records{{/monospace}} macro (XWIKI-24831), which maps onto the same Live Data renderer.
* The *standalone* WYSIWYG editor ( \ {{ monospace}} ?editor=wysiwyg {{/monospace }}) is a different and
already-known problem: there the Live Data never renders at all, before or after a Source round
trip, only a loading spinner is shown. That one is explained by XWIKI-22781 (JavaScript skin
extensions are not loaded in the standalone editor). The bug reported here is about the *in-place*
editor, where the Live Data does render on entering edit mode and stops rendering only after the
Source round trip.
* Verified on 18.8.0-SNAPSHOT (master). The code paths involved date back to 2020 (CKEDITOR-328), so
older versions are very likely affected too, but this has not been verified on the LTS - hence the
Affects Version below is the most recent LTS rather than a verified oldest version.
h2. Related issues
* XWIKI-22046 - blank-output macros get no placeholder or existence indicator in the editor (why the
macro is not even selectable here).
* XWIKI-22781 - JavaScript skin extensions are not loaded in the standalone WYSIWYG editor (the
separate standalone symptom).
* XWIKI-24096 - some macros don't execute properly when editing the source of a page in the in-place
editor and saving from there (same editor, adjacent path).
|
|
