Saving a page with VisualEditor duplicates the page content till refresh

[andrewdbate]

Update: This bug has also been filed with the VisualEditor extension as T282805.

The Attachments extension does not work correctly when used with the VisualEditor.

I describe the problem in the following screenshots:

1. Start with a page that you would like to edit. (This example page has attachments, but the same thing happens irrespective of whether the page has attachments. The key thing is that the Attachments extension is enabled for the wiki.)

---

2. Click on the Edit tab to go to the VisualEditor.
This now shows the VisualEditor as expected. (The Attachments section does not show, but this is as expected.)

---

3. Make the edit that you'd like to make.
I have added the text "This is my edit". So far so good.

---

4. Click "Save changes..." to save the edit.
Still working so far.

---

5. Clicking "Save changes" to save and go back to the article.
This is the where you get the visual glitch. You can see from the screenshot below that the article contents is shown twice, and the attachments section is not showing.

---

6. Refreshing the page, it displays as expected.
If you refresh the page, then the article shows once as expected, and the Attachments section is now shown at the bottom.

---

The cause of the problem

The attachments section is wrapped in a div with id ext-attachments. This issue described above happens because this div also has the class mw-parser-output.

The page already had one div with class mw-parser-output that wraps the article. So now the page has two divs with class mw-parser-output (the second introduced by the Attachments extension).

It seems that the VisualEditor looks for all elements with class mw-parser-output when refreshing the page and replaces their content after saving the edit. So that is why the article shows twice, and the attachments section does not show at all.

The code that generates the ext-attachments div for the attachments section is in AttachmentsHooks.php on line 70.

If you remove the mw-parser-output class from the ext-attachments div generated by AttachmentsHooks.php then the VisualEditor works as expected.

Workarounds for external links

It seems that class mw-parser-output was only added to the ext-attachments div was so that external link attachments had the external link icon (when using the Vector skin).

The relevant lines from the typography.less file from the Vector skin:

// External links
.mw-parser-output {
	.external {
		background-position: center right;
		background-repeat: no-repeat;
		.background-image-svg( 'images/external-link-ltr-icon.svg', 'images/external-link-ltr-icon.png' );
		padding-right: 13px;
	}
}

The style assumes that each external link is a child element of mw-parser-output.

Initial workaround attempt: I removed the class mw-parser-output class from the ext-attachments div, but added a span with class mw-parser-output around each external link tag <a> by modifying Attachments.php. However, while this shows the external link icon correctly, the VisualEditor again showed the article content for each span with class mw-parser-output after saving edits. So this attempt does not work.

The best workaround might therefore be to copy the external link styling from the Vector skin to a new class. Then in the makeList function test if the skin is Vector, and if so add the class to the external links <a> anchor elements.

Ideally, MediaWiki would change the Vector skins typography.less file so that such workarounds are not required.

[Gittenburg]

Wow, thank you very much for this detailed report!

I assume you are using the latest versions of MediaWiki and VisualEditor? I tried to reproduce the problem locally with the latest versions but I am struggling to get VisualEditor to work at all behind NGINX (when attempting to open it I get an Error contacting the Parsoid/RESTBase server (HTTP 404)).

I failed to reproduce the bug with a wiki using MediaWiki 1.35.1 and VisualEditor 0.1.2. Apparently with that setup saving in the visual editor doesn't update the page dynamically but refreshes the complete page, so the bug doesn't occur.

Anyway I'd rather not duplicate CSS from the Vector skin because that will just lead to inconsistencies in the future. And I don't think the problem lies with the Vector skin ... other skins will probably also style .mw-parser-output .external.

So I think the best solution would be if VisualEditor could refine it's element selection to only target the first .mw-parser-output. I opened a respective Phabricator task.

btw while attempting to reproduce this I discovered yet another VisualEditor issue (#9), I am curious if you can reproduce it.

[andrewdbate]

The above bug was using MediaWiki 1.35.2 (which comes with VisualEditor 0.1.2).

However, I just downgraded to MediaWiki 1.35.1 (which also comes with VisualEditor 0.1.2) and I reproduced the same bug again.

Perhaps there is some difference in our setups so that my VisualEditor does a refresh after page save whereas your VisualEditor does not?

I also had the error Error contacting the Parsoid/RESTBase server (HTTP 404) at some point when I set up VisualEditor, and I had to change my NGINX config for the Parsoid REST API. I can send you my NGINX config if that would be useful.

I will comment on issue (#9) if I can reproduce it or not.

[Gittenburg]

Thanks for the info! After managing to correctly set up nginx (had to make sure that /rest.php/v1/page/Main_Page was properly routed) I can easily reproduce the bug with 1.35.2.

I got curious why I couldn't reproduce it with the other wiki and investigated. It turns out that I was encountering an edge case: with $wgVisualEditorDisableForAnons = true; VisualEditor refreshes the page after edits for anonymous editors.