Page MenuHomePhabricator

For very large pages on slow connections (when a timeout happens?), users get an "Error: Unknown error" on saving changes in VisualEditor (but change is indeed saved)
Open, MediumPublic

Description

It first happened to the user who was trying to add a wikilink to a large page, https://en.wikipedia.org/wiki/List_of_Criterion_Collection_DVD_and_Blu-ray_releases; he got the error while in VE so he made that edit with the classic editor later.
He then copied the contents of the page to a sandbox - https://en.wikipedia.org/wiki/User:Marc_Kupper/sandbox2 - for further testing and these are his findings:

<< It took 74 seconds to load the page in VE, I made the change, save-page, give a reason (wikilink - testing VE), save-page again. After 1:45 (105 seconds) I got "Error: Unknown error" in the lower part of VE's edit-summary box. The save-page button is grayed out.
I don't think the actual edit I did matters. If someone wants to reproduce using my sandbox then the edit was in the last paragraph of the lead. Where it says "...Essential Art House, Eclipse, and Merchant Ivory Collection..." I changed "Eclipse" to [[Eclipse (DVD)|Eclipse]] by double-clicking on Eclipse to select, control-K to bring up the insert/edit link box, appending " (d" to the link-to value, click "Eclipse (DVD)" in the list of offerings, and then press <enter> a couple of times to close out the box. I suspect you can make any change you want. --Marc Kupper|talk 22:06, 19 August 2013 (UTC)

After documenting how I did the edit I tried the save again and again got the error. It happened 1:44 (104 seconds) after clicking save. I suspect the 105 seconds above is simply because I was a bit slow reacting as this time I was waiting for the error right around the 1:45 mark. --Marc Kupper|talk 22:06, 19 August 2013 (UTC)
I then did the following tests
I replaced all non-alphabetic characters with the letter "x" and can edit the page with VE. It appears the issue is with something in the page content, possibly combined with the page size.
I removed all 'ref' tags. Saving from VE still fails after 1:44
I removed most of the templates transcluded on the page. Saving with VE worked and took 1:17. However, I had intended to just add "xxx" in the middle of a word. VE also stripped a table in another part of the article of wikitext. (https://en.wikipedia.org/w/index.php?title=User%3AMarc_Kupper%2Fsandbox2&diff=569295763&oldid=569295507 ) --Marc Kupper|talk 23:16, 19 August 2013 (UTC)

I don't have time to debug this further at present - particularly as we now have two VE issues. The next step is to revert back to 22:48, 19 August 2013 and to then see if I can narrow it down from there. --Marc Kupper|talk 23:11, 19 August 2013 (UTC) >>

I tested on the first version of the sandbox as well, it took me almost 75 secs as well to load the page, I wikilinked a word and then hit Save - it took me 2min 15sec to get the error message while actually the edit was saved. Thanks.


Version: unspecified
Severity: major
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=70726
https://bugzilla.wikimedia.org/show_bug.cgi?id=51636

Details

Reference
bz53093

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 2:02 AM
bzimport set Reference to bz53093.

(User specs, Vista - FF23 - Vector.)

Here http://en.wikipedia.org/w/index.php?title=Fairfield%2C_Iowa&diff=569923054&oldid=569069756 is another case of the error message being thrown after an actually successful edit.
The user wonders: " it would be useful to know the current confidence limits around page length and the ability to edit same. Is it dependent upon local environment (i.e. PC configuration and memory allocated to browser)? Or is there a server side known performance limit?".
Thanks.

David Gerard and I had different experiences about this bug.
He tried to edit https://en.wikipedia.org/wiki/Neuro-linguistic_programming , while I basically copy/pasted that article in my sandbox https://en.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/Sandbox&oldid=573778358 and then attempted to change it.
After 100 secs or so, VE managed to save our edits, but he got the error message, while I didn't. HTH.

A fr.wp user reports he was confused when he got this message, since the edit was saved anyway.

I got "Error: unknown error", but the error saved anyway, on this edit: https://en.wikipedia.org/w/index.php?title=OpenOffice.org&curid=68227&diff=574513723&oldid=574510970 - first time I've ever had the error and it did in fact save.

I'm now wondering if having the error and the edit not being saved is the same bug as having the error and the edit being saved.

Ok, so comment #3 should read that in one occasion,
David got the message, the edit was not saved.
Editing the same article, I didn't get the message, and my edit was saved.
In other cases, it is possible to get the message and having the edit saved.

At
https://en.wikipedia.org/wiki/List_of_Criterion_Collection_DVD_and_Blu-ray_releases?veaction=edit,
I am seeing a 5.6mb upload on preview. This takes 47 seconds to transfer
using my DSL connection. Connections with slower upload speeds would do
worse, and possibly time out. The POST processing and response then
takes 7.9 seconds according to the Chromium network console.

For comparison, the HTML downloaded on VE open is 238kb in size and
takes 3 seconds to load. Total load time until VE is ready is around 36
seconds, again using Chromium.

In my experience Firefox's client-side processing would be a bit slower.

Some additional info about the POST size issue on save:

To check the POST request size, I looked at the Content-Size header in the request headers once that completed (request to api.php started when opening the save dialog).

The issue does not seem to be specific to any particular page. At https://en.wikipedia.org/wiki/OpenOffice.org?veaction=edit for example an initial
load of 215k turns into a 3.6mb POST.

Possible remedies:

  • use gzip compression for the POST request body
  • use multipart/form-data POST encoding instead of application/x-ww-form-urlencoded to avoid percent encoding overhead
  • send HTML as a separate POST variable without JSON wrapper to avoid JSON escaping, in particular of quotes

Strike the last point about JSON- the HTML is already sent as a plain query parameter without JSON wrapper.

Jdforrester-WMF renamed this task from VisualEditor: For very large pages on slow connections (when a timeout happens?), users get an "Error: Unknown error" on saving changes (but change is indeed saved) to For very large pages on slow connections (when a timeout happens?), users get an "Error: Unknown error" on saving changes in VisualEditor (but change is indeed saved).Dec 2 2014, 9:54 PM
Jdforrester-WMF set Security to None.
Jdforrester-WMF lowered the priority of this task from High to Medium.Jan 15 2015, 12:46 AM

Some additional info about the POST size issue on save:

To check the POST request size, I looked at the Content-Size header in the request headers once that completed (request to api.php started when opening the save dialog).

The issue does not seem to be specific to any particular page. At https://en.wikipedia.org/wiki/OpenOffice.org?veaction=edit for example an initial
load of 215k turns into a 3.6mb POST.

You're saying that the page downloads gzipped at a weight of 215k and then when the browser goes to re-upload it has a weight of 3.6mb uncompressed? That sounds pretty bad to me.

The issue does not seem to be specific to any particular page. At https://en.wikipedia.org/wiki/OpenOffice.org?veaction=edit for example an initial
load of 215k turns into a 3.6mb POST.

Possible remedies:

  • use gzip compression for the POST request body
  • use multipart/form-data POST encoding instead of application/x-ww-form-urlencoded to avoid percent encoding overhead
  • send HTML as a separate POST variable without JSON wrapper to avoid JSON escaping, in particular of quotes

Where are you seeing this? VE already does all of these things, which I just confirmed at https://en.wikipedia.org/wiki/OpenOffice.org?veaction=edit in Chrome. The POST that occurs when the (first) save button is pressed has a multipart/form-data POST body with gzipped content (the value of the html parameter starts with rawdeflate,7H1rd9tGkuj3+RW9). The POST that occurs when the second save button is pressed only sends a cachekey value, no large blob of HTML.

You should not have been able to trigger a multi-megabyte POST upload. Perhaps you observed a cachekey miss and there's a bug where the POST body is not compressed in that case?