I can't save existing pages on any WMF wiki using VisualEditor on Internet Explorer 11. When I click "Save page" in the edit summary dialog I see
Something went wrong parsoidserver-http: HTTP 400
(Then, when I dismiss that message, the "Save page" button in the dialog box remains grayed out. Separate bug.)
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • GWicke | T112286 Reports of 400 and 500 errors with Parsoid | |||
| Resolved | Esanders | T113163 Cannot save existing pages using IE11 |
I could create https://test.wikipedia.org/wiki/Ham using VE on IE11. But editing more complex pages seems to fail.
Same issue here. I'll test further when I get home to try and ensure this isn't just my network
Is this actually specific to IE11? Do the exact same edits work in other browsers? If so, can you identify what parts of the edit suddenly cause it to fail – links, references, headings, tables?
I can create new pages but not edit existing ones.
It is specific to IE11 insofar as I can compare it with Firefox; I am not able to test other IE versions at the moment.
What TTO says. Editing even almost empty pages (like Ham) won't work, but I managed to create one (Hamster).
I tried with my sandbox at it.wp, and got the same error message.
Other browsers seem to be working just fine.
At a glance it looks like the HTML we are preparing to send is the same in IE11 as it in in Chrome (ve.init.target.suface.getHtml())
HTML generated by IE11:
<!doctype html> <html about="http://www.mediawiki.org/wiki/Special:Redirect/revision/1899051" prefix="dc: http://purl.org/dc/terms/ mw: http://mediawiki.org/rdf/"> <head prefix="mwr: http://www.mediawiki.org/wiki/Special:Redirect/"> <meta content="068eee61-62e6-11e5-bae3-31733ee1a177" property="mw:TimeUuid" /> <meta content="2" property="mw:articleNamespace" /> <link rel="dc:replaces" resource="mwr:revision/0" /> <meta content="2015-09-24T17:59:39.000Z" property="dc:modified" /> <meta about="mwr:user/823762" content="ESanders (WMF)" property="dc:title" /> <link rel="dc:contributor" resource="mwr:user/823762" /> <meta content="a94a8fe5ccb19ba61c4c0873d391e987982fbbd3" property="mw:revisionSHA1" /> <meta content="test" property="dc:description" /> <meta content="0" property="mw:parsoidVersion" /> <link href="//www.mediawiki.org/wiki/User%3AESanders_(WMF)/sandbox2" rel="dc:isVersionOf" /> <title>User:ESanders_(WMF)/sandbox2 </title> <base href="https://www.mediawiki.org/wiki/" /> <link href="//www.mediawiki.org/w/load.php?modules=mediawiki.legacy.commonPrint,shared|mediawiki.skinning.elements|mediawiki.skinning.content|mediawiki.skinning.interface|skins.vector.styles|site|mediawiki.skinning.content.parsoid|ext.cite.style&only=styles&skin=vector" rel="stylesheet" /> </head> <body lang="en" dir="ltr" class="mw-content-ltr sitedir-ltr ltr mw-body mw-body-content mediawiki" id="mwAA"> <p id="mwAQ">testx</p> </body> </html>
Diffing this against HTML generated by Chrome, all I can see is
Also I have tested IE11 locally without RestBase and it works fine.
Cited the wrong line :P The correct one is mods/parsoid.js#512.
Edit: in reality, we expect the property field to come before content, but IE(11) arranges them inversely.
Wait .. I am confused now. So, the meta-tag is in the <body> in the HTML that comes from VE in the case of Firefox, chrome, etc?
<speculation> This could just be IE11 enforcing standards and hoisting the meta tag into the <head> section .. and since RESTBase started enforcing the presence of the tid and is looking for it in the <body>, this might be failing. </speculation>
We look in the body of the request (which may or may not contain a <head> section). I have yet to confirm it, but I really think that the problem here is that we expect property to come before content, so the regex isn't matching it. I'll test this theory tomorrow :)
That seems right: <meta content="068eee61-62e6-11e5-bae3-31733ee1a177" property="mw:TimeUuid" />
Aha .. look at the regexp .. /<meta property="mw:TimeUuid" content="([^"]+)"\/?>/ .. no \s* before the /? .. that is the bug.
Sorry, no, Marko said that the order of content and property is enforced one way while IE serializes it the other way. But the whitespace thing is probably an issue too, good catch.
Clearly, I am not reading well late in the evening. :) but that as well. So, 2 bugs in that regexp then.
While we can tweak the regexp to work around the concrete IE issue, the meta tag was never meant to be more than a temporary fall-back hack to support clients that don't supply the If-Match header yet. This might be a good point to finally phase out the meta hack, and move towards requiring If-Match in the request. See also https://github.com/wikimedia/restbase/pull/355#issuecomment-143110757 for a related discussion about the transform API.
Indeed @ssastry thnx for catching this subtlety! PR 357 fixes both of these issues.
This fix was a rather easy one, so I see no reason not to include it at this point. But I completely agree with @GWicke and would like to voice the same request. Could VE get rid of it and send the proper header instead? This bug tells me that this is not the last time we're going to have discrepancies because of the difference in browser renderings.
PR 357 has been deployed in production, so resolving the ticket. If the issue still persists, please reopen it.
I opened T113728: VE should send If-Match header to the VRS to send on to RESTbase to continue the discussion about setting the If-Match header.