What is the exact error message? After "Revision IDs returned by the server do not match", it should show the actual revision IDs.

They should both be numbers; if they're not, please follow the instructions at T306048#7915175 to see what exactly are the API responses. You might discover that something outside VE is actually displaying an error, but not reporting it properly, so VE is trying to edit the error message as if it was the page content.

Sorry, I just triggered it now and it said

Revision IDs returned by the server do not match (document: undefined, metadata: 1).

Following to that other ticket, I can see my browser request "/wiki/api.php?action=visualeditor&format=json&paction=parse&page=Main_Page&uselang=en&formatversion=2&oldid=1", but I do not see a "/api_rest" redirect - it goes straight to the popup error - there is no other page. That might explain why the error says "undefined"?

Found the problem. I forgot that we were using mod_auth_mellon (SAML) to protect the wiki, so that was turned on in front of mediawiki (ie apache was using it to require authentication before you even get to the front page). I was going to use the Auth_remoteuser extension to enable our staff to SSO into the wiki - but hadn't actually got that far so didn't originally think it was related. However, it appears that somehow mod_auth_mellon is interfering, because once I disabled it the problem disappeared.

mod_auth_mellon relies on Cookies, but from a PHP perspective I wouldn't think it would even be noticed - so I'm a bit lost as to how this could cause any problem - but it is.

BTW I also re-enabled mod_auth_mellon and the problem returns - so it's definitely the problem. This is actually a system replacement: the old system was CentOS6+mod_auth_mellon+old-mediawiki - and that worked splendidly - so I know this should work in theory.

I also just ran up the Web dev tools in the browser again (with mod_auth_saml enabled) and there is no sign of any HTTP 401 errors or the like - they are all HTTP 200 and all contain the Cookies mod_auth_saml relies on - plus my mediawiki logged-in-user-cookies. I dunno what's going on :-(

Following to that other ticket, I can see my browser request "/wiki/api.php?action=visualeditor&format=json&paction=parse&page=Main_Page&uselang=en&formatversion=2&oldid=1", but I do not see a "/api_rest" redirect - it goes straight to the popup error - there is no other page. That might explain why the error says "undefined"?

Oh, that's actually normal – depending on the site configuration, everything in the second request might already be included in the first. I forgot about that.

mod_auth_mellon relies on Cookies, but from a PHP perspective I wouldn't think it would even be noticed - so I'm a bit lost as to how this could cause any problem - but it is.

If cookies are the only problem, then this might work for you: https://www.mediawiki.org/wiki/Extension:VisualEditor#Forwarding_cookies_to_Parsoid

This problem occurs because we actually make an internal HTTP request from MediaWiki to itself to fetch the page contents for editing. This is ugly and a historical accident (it used to be a separate service that was later merged into MediaWiki). Good news is that it will finally be cleaned up in MW 1.39 (T305108), so this problem should also disappear.

Argh. That means I have to enable HTTP (I deliberated hadn't because - well - it's 2022 ;-), and then I'll have to figure out how to stop mod_auth_mellon erroring when it sees the lack of HTTPS, etc. I've had a go and can't get anywhere. I think I'll give up on VisualEditor and wait until the old Parasoid code is properly torn out/rewritten. Thankfully this is a "99.999% read - with the odd write" wiki, so having a fancy editor isn't a major issue

Thanks for the help!

Jason

Should be fixed in MW1.39 due to T305108: Zero Config Install of VE + Parsoid for MW 1.39.