On Beta cluster I can't open mobile VE when I click on the Edit icon.
There is no error in the console, it's just not doing anything
Description
Event Timeline
Hmm, I tried this page: https://en.m.wikipedia.beta.wmflabs.org/wiki/User:RYasmeen_(WMF) on a mobile device.
Okay I am gonna mark it as UBN, since it makes mobile VE totally unusable for certain pages.
Actually, I don't think it's about maps, it's also not opening for this page which only has one line text: https://en.m.wikipedia.beta.wmflabs.org/wiki/Newpageload
This might be unrelated, but when opening the mobile editor in wikitext mode for that page, it works for me. Switching to Visual mode instead, the thing crashes and goes back to read mode. No error is logged to the console, but I do see in the network panel that the request to Beta Cluster's Parsoid for https://en.m.wikipedia.beta.wmflabs.org/wiki/Newpageload is responding successfully... with the contents of an unrelated page, the wiki's Main Page:
https://en.m.wikipedia.beta.wmflabs.org/api/rest_v1/page/html/Newpageload/378098?redirect=false
That might be part of the problem.
I tried to edit https://en.m.wikipedia.beta.wmflabs.org/wiki/User:RYasmeen_(WMF)?debug=1 and stepped through all the init code line by line to find out where it fails. And it fails here:
this.loadFail( 've-api', 'Revision IDs (doc=' + docRevId + ',api=' + this.revid + ') ' + 'returned by server do not match' );
When it fails, docRevId = 377057, this.revid = 384154. Revision 377057 actually is a revision of a different page: https://en.m.wikipedia.beta.wmflabs.org/?oldid=377057
In hindsight, I could have found it out more easily by editing on desktop, which actually shows the error message: https://en.wikipedia.beta.wmflabs.org/wiki/User:RYasmeen_(WMF)?veaction=edit
Looks like the REST API is returning some bogus results. I don't think it's a VE bug.
The REST API is returning the correct, latest revision, which is 384154. It seems to me that 377057 is somehow being set by VE, as asking the REST API for a revision of a title that doesn't match the title would result in a client error (which is not the case here).
But, weirdly, I cannot reproduce this problem. When I ve-edit the page, VE opens just fine for me (on desktop).
It seems to be working correctly now, but as evidenced by the screenshots, it was not working correctly this morning.
It is a bit upsetting if it magically broke and then fixed itself with no human intervention.
While this is a serious issue, I don't think it is a blocker for 1.32.0-wmf.23 deployment:
- The bug seems like it is in RESTBase rather than MediaWiki, so deploying a new MW version shouldn't affect it
- VE actually detects the erroneous results from the REST API and shows an error (if it didn't, user trying to save the changes could replace the page with unrelated content)
- It's not happening right now and we don't know how to reproduce it…
Here's a guess.
377057 is the latest revision of the Main_Page.
VE is asking for 1.7 content from Parsoid,
https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/master/includes/ApiVisualEditor.php#L101
RESTBase is hitting https://github.com/wikimedia/restbase/pull/1069 since the stored version is 1.8 and asking for a downgraded version from Parsoid but not specifying a title or revid and something is going wrong there?
I've tried various things in RB but I simply can't get RB to respond with 377057.
curl 'localhost:7231/en.wikipedia.beta.wmflabs.org/v1/page/html/User:RYasmeen_(WMF)' -H'Accept: text/html; charset=utf-8; profile="https://www.mediawiki.org/wiki/Specs/HTML/1.7.0"' results in a 200 that returns the rev 384154 with the content type text/html; charset=utf-8; profile="https://www.mediawiki.org/wiki/Specs/HTML/1.8.0". Same for requesting localhost:7231/en.wikipedia.beta.wmflabs.org/v1/page/html/User:RYasmeen_(WMF)/384154.
Well, if I do,
arlolra@deployment-restbase01:~$ curl 'localhost:7231/en.wikipedia.beta.wmflabs.org/v1/page/html/Tony_Pittman' -H'Accept: text/html; charset=utf-8; profile="https://www.mediawiki.org/wiki/Specs/HTML/1.7.0"' <!DOCTYPE html> <html prefix="dc: http://purl.org/dc/terms/ mw: http://mediawiki.org/rdf/" about="https://en.wikipedia.beta.wmflabs.org/wiki/Special:Redirect/revision/377057"><head prefix="mwr: https://en.wikipedia.beta.wmflabs.org/wiki/Special:Redirect/"><meta charset="utf-8"/><meta property="mw:pageNamespace" content="0"/><meta property="mw:pageId" content="1"/><link rel="dc:replaces" resource="mwr:revision/354925"/><meta property="dc:modified" content="2018-03-18T05:52:05.000Z"/><meta property="mw:revisionSHA1" content="bcc5ae94bcb801b45c98c7645e296be1eff60027"/><meta property="isMainPage" content="true"/><meta property="mw:html:version" content="1.8.0"/><link rel="dc:isVersionOf" href="https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page"/><title>Main Page</title> ...
vs
arlolra@deployment-restbase01:~$ curl 'localhost:7231/en.wikipedia.beta.wmflabs.org/v1/page/html/Tony_Pittman' <!DOCTYPE html> <html prefix="dc: http://purl.org/dc/terms/ mw: http://mediawiki.org/rdf/" about="https://en.wikipedia.beta.wmflabs.org/wiki/Special:Redirect/revision/52317"><head prefix="mwr: https://en.wikipedia.beta.wmflabs.org/wiki/Special:Redirect/"><meta property="mw:TimeUuid" content="6dba5705-abc7-11e8-abcc-98dcecb75195"/><meta charset="utf-8"/><meta property="mw:pageNamespace" content="0"/><meta property="mw:pageId" content="3504"/><link rel="dc:replaces" resource="mwr:revision/0"/><meta property="dc:modified" content="2011-09-27T05:32:19.000Z"/><meta property="mw:revisionSHA1" content="10b4ced549cacadc636c6f9d56e00f8932ed6408"/><meta property="mw:html:version" content="1.8.0"/><link rel="dc:isVersionOf" href="https://en.wikipedia.beta.wmflabs.org/wiki/Tony_Pittman"/><title>Tony Pittman</title> ...
Note that the original issue found, as well as VisualEditor's logic in general, always asks for ?redirect=false. Might be unrelated, but just noting it here.
The stored content for User:RYasmeen_(WMF)/384154 is now at 2.0.0, which downgrades just fine, since it's a major version downgrade, and is probably why you couldn't reproduce this. The bug is somewhere in that minor version downgrade path.
To elucidate why the Main_Page was showing up,
- VE requests 1.7
- RB has 1.8 stored, asked to downgrade it (that was the bug fixed in PR1069 since 1.8 should satisfy 1.7)
- The downgrade request is posted w/o a title or revid
- Parsoid knows that original content already satisfies the requested version, so determines this is a reparse request (and, unfortunately, mistakenly tries to reuse parts of the original content where it can (though that's
brokendisabled so not a huge concern)) - The reparse uses the default title, Main_Page, since none was provided
Other than the fix that was applied, is there anything required?
Hmm, I am still not being able to open those pages with mobile VE. Shouldn't the fix that was applied work by now?
@Ryasmeen can you list the titles you are trying now? I bet my right hand it's Varnish cached something wrong.
The second page is loading now with VE, but the first page still doesn't for some reason.