Thanks @Nux. I tried the same operations in Firefox on Linux and they work fine. So it does seem like a Chrome issue.

I just tried out the fix in WikiEditor on en.wikipedia.org using the latest Chrome on Linux. The behavior is better than before, but still strange. Here are steps to reproduce:

Thanks, @matmarex. For this request, api.php?action=visualeditor&format=json&paction=parse&page=Test_page&uselang=en&formatversion=2, I get an unexpected response that begins like this:

Sure, if you can provide instructions for me to see those responses, so I can copy them into this ticket.

This bug is a duplicate of T306048 and can be closed.

Related issues;

Screenshot.

Behavior confirmed in latest MW 1.37.2 as well.

Update: After making no configuration changes at all, VisualEditor now fails 100% of the time on invocation, displaying a similar error:

Thanks for the patch. I appreciate your work!

If I understand your patch correctly, you're removing all whitespace from the name, instead of just trailing whitespace before the file extension. Is that what you meant to do?

1. On your hard drive, create an image file named Foobar .jpg with a space before the dot.
2. Visit Special:Upload, browse to this filename, and select it.
3. Notice that on Special:Upload, the Destination filename is Foobar_.jpg.

I have encountered this exact error on a fresh install of MediaWiki 1.37.1 with no extensions other than VisualEditor and WikiEditor. Editing with WikiEditor works perfectly.

Thanks!

@Izno - Would you please provide a link to docs on how to create such a user script? Thank you.

Screenshot of the error (showing VisualEditor's state):

In case this helps: setting $wgForceHTTPS does not make VisualEditor work:

@matmarex : Yes, setting $wgCanonicalServer as follows makes VisualEditor work:

I can confirm that my four wikis, which were unable to use VisualEditor, are now fixed. :-)

I restricted my test wiki to disallow anonymous edits:

@AndrewDBate - yes indeed, my LocalSettings.php did not include any $wgGroupPermissions changes. It is possible that two separate issues are masquerading as one issue:

The protocol-relative URL bug is now T299175.

I discovered the cause of the problem (documented in the previous comment). Changing this line in LocalSettings.php, which specifies a protocol-relative URL:

OK, I just went through an extensive debugging session for this problem (Error contacting the Parsoid/RESTBase server (HTTP 415) on save operations). I created a MediaWiki 1.37.1 test site with a minimal LocalSettings.php file plus VisualEditor. There are no $wgGroupPermissions statements at all, so wiki permissions should not be an issue -- the test site is wide open for anonymous editing.

Ah, found some REST docs. @AndrewDBate, does this successful GET request prove that Parsoid is running on the given server?

Thanks @AndrewDBate. I really appreciate all of your advice.

A-ha... if I make my private wiki use http instead of https (by changing the Apache configuration), VisualEditor can save pages without error, without needing any of the workarounds in this ticket.

@AndrewDBate: I finally had a chance to try your error-logging alternative:

@M4rkusd89: Thanks for the suggestion. php-curl is already installed on my server, so your fix may be necessary for VisualEditor but it's not sufficient to solve the problem.

Ooo, this might explain the weird wfDebug behavior. From https://www.mediawiki.org/wiki/Manual:How_to_debug#Logging:

I don't have an explanation but I do have a better analysis.

Thanks @AndrewDBate. I suspect the issues with the MediaWiki debug log were due to heavy caching -- I'd modify LocalSettings to enable debugging but MediaWiki wouldn't pick up that fact and wouldn't reread it.

Thanks @AndrewDBate for your debugging help! Yes, in the big table output by this script:

<?php
phpinfo();

Thanks @AndrewDBate! I did exactly as you said, and both $_SERVER['REMOTE_ADDR']) and $_SERVER['SERVER_ADDR']) are the empty string.

@AndrewDBate: Your workaround unfortunately does not work for me with MediaWiki 1.35.3. I still get this error from VisualEditor on save:

I'm being bitten by this bug on a wiki that permits anonymous reads and forbids anonymous writes. None of the suggested workarounds work for me.

Glad to hear it! This was a tough bug to notice. I kept thinking it was my fault for clicking imprecisely. :-)

Thanks for testing! My setup was Chrome on Ubuntu Linux 18.04.

The bad behavior is still present. I can confirm that in MediaWiki 1.35.1, I can upload an image file and name it foo .jpg including a space character before the .jpg extension.

Thank you so much! Sorry for taking up your time.

No, I haven't seen it for a long time. Thanks.

Thank you for the suggestion, @Ammarpad. I added this line to LocalSettings.php:

FYI, I also just added application/epub+zip to /etc/mime.types (on my Ubuntu 18.04 system)

@Ammarpad - Thank you for the suggestion about the MIME type. I don't know much about epub files, but when I unzip my file, I see:

@Aklapper: I am pretty sure your response is incorrect. This syntax appends the given value to the array:

Thanks. I upgraded to 1.31.5 a few hours ago. :-)

Works for me! Thanks so much, @Seb35!!

Still a problem in MediaWiki 1.29.1.

@zhuyifei1999 Yes, the current code successfully logs into a private wiki. There are some warnings, but the same warnings were already present before the changes.

The error behavior has changed in the current version of pywikibot. The error is now RuntimeError: Unable to determine articlepath.

@Anomie - thanks for the info. Would the following be a correct fix within Pywikibot?

@zhuyifei1999 - Thanks for the suggestion. This wiki is inside of a corporation that uses another authentication method.

Any estimate on when you might address this issue? Pywikibot is completely unusable on all wikis that require logins to read.

@matmarex - Thanks so much for your extremely clear and detailed explanation. Thanks to you, I have updated the affected extension on our wiki, and it's now working perfectly. I also appreciate very much that the docs will be updated.

Is there any kind of workaround for this issue? Our wiki hasn't been able to use Pywikibot for 4 months....

You sure that T153346 is the same onBeforeUnload issue as this ticket?

Suggestion: Allow the user to provide the missing site information, either on the command line (using options), in a configuration file, or during script execution if the script can prompt the user interactively.

This problem no longer occurs in MediaWiki 1.28.0, with the Linker class (deprecated) replaced by calls to LinkRenderer.

This can be closed.

Looks like someone already patched this for bug T151973:

Thank you for making the patch. Interestingly, I filed this bug report against a different extension that's also named DynamicPageList. I found the bug in the third-party extension known as DynamicPageList2, Your patch is against the original DynamicPageList from Wikimedia.

Finally managed to have time to get developer access, and submitted the patch above. This bug has been around for 3 releases, so hopefully this will eliminate it.