Topic on VisualEditor/Feedback

Apparently, VE gives up when it is fed a very huge document: https://en.wikipedia.org/wiki/List_of_named_minor_planets_(numerical)

This seems to be due to a deliberate constraint placed on these documents: https://phabricator.wikimedia.org/T120972

Steps: Load article using Chrome , e.g. https://en.wikipedia.org/wiki/List_of_named_minor_planets_(numerical)?veaction=edit Expected: If document can't load, fallback to regular editor or show a more informative error message instead of "HTTP 413"

Actual: Dialog with error message: "HTTP 413"

Proof, popcorn action, etc (might be a good idea to save the results) : https://www.webpagetest.org/result/170130_7Y_Y0R/

Perhaps this is different for anon vs reg editors...

P.S. That page has what can only be described as an insane amount of inline styling. It seems to make an older firefox 46 cough blood, and consume huge amounts of memory and cpu just to load the normal article for reading.

Someone should really teach wimipedians that excessive inline styling and linking not only makes editing a mess but also makes basic reading of an article a serious problem.

I get "Error loading data from server: HTTP 413". What is your specific request here?

Well, primarily more descriptive message, secondarily, a more intuitive fallback to reading mode.

That's what cancel means in most contexts, stop and go back to whatever the user was doing. "Error loading data from server" is uninformative. It could be a network error on the user's side, or a server error (it is the latter in this case). So one suggestion would be to improve the error message to something like "The editor cannot load (Error: HTTP 413).", or alternatively leave that message and add a header to the dialog box, "Editor loading error".

When it can't load the expectation would be to be sent back to reading mode, instead one gets sent to an alternative editor which may be confusing for someone who's never edited using wikitext.

As a general rule, if an end-user has to use a search engine to understand an error message that is a good sign that it needs improvements.

That there are limits should not be surprising, we have lots of them. :)

The error handling should indeed be improved here. When you press cancel, VE seems to basically stop everything it was doing and drops you into a confusing twilight mode between reading and editing, that is not very helpful to average users.

But also.. that page is insane. Lovely testcase, but insane. :)

Limits aren't surprising, frozen browsers are, firefox did freeze before showing that dialog a couple of minutes later, and that is certainly a bug.

It would probably be prudent to store the insane nature of the article maybe in the parser limit report or somewhere else to prevent VE from even trying to load that article, and instead show a user friendly message before the browser freezes and dies.

For webpagetest to even show that dialog in the screenshot the timeout limit had to be raised to about 100 seconds. Without it the tool would just give up. before showing the dialog.

When I open that page in VisualEditor (visual mode) in Safari 10, I get the 413 error after about 12 seconds. Clicking the "Cancel" button drops me into VisualEditor's wikitext mode after a delay of about 16 seconds.

When I open that page on the same Mac in Firefox 50 (as a logged-out editor this time, since you're not logged in), it takes about 40 seconds to get to the error message, and about 20 seconds to get dumped into the 2010 wikitext editor.

I have no idea why Firefox 50 is so much slower than Safari 10. (I have more tabs open in Firefox; maybe that explains some of the speed difference, but it seems to be a general trend.)

Also, what's your operating system? I've been considering a theory that it's faster on a Mac than on Windows.

> I have no idea why Firefox 50 is so much slower than Safari 10.

Different browsers different technology or software. There may be optimizations Safari or Chrome has that Firefox doesn't.

>Also, what's your operating system? I've been considering a theory that it's faster on a Mac than on Windows.

Fedora core 22 (linux)

> have more tabs open in Firefox; maybe that explains some of the speed difference, but it seems to be a general trend.

More tabs consume more memory, so it is entirely possible that it becomes worse with more tabs open. In my case I opened just one only to see if the loading problem was specific to chrome.