BUG #16063: Error retrieving data from the server: INTERNAL SERVER ERROR: string indices must be integers

The following bug has been logged on the website:

Bug reference: 16063
Logged by: Bart Hofland
Email address: bart(dot)hofland(dot)2(at)gmail(dot)com
PostgreSQL version: 12.0
Operating system: Windows 10 (Version 10.0.18352.418)
Description:

On Thu, May 23, 2019, Stefan Wolf reported a bug (#15816): when clicking on
a database node in the browser pane, the server responds with "Error
retrieving data from the server: INTERNAL SERVER ERROR: string indices must
be integers".

On Fri, May 24, 2019, Fahar Abbas wrote that pgAdmin4 did not support v12
yet and referred to issue 4283 in the bugtracker as well. That issue 4283
seems to have been completely resolved in sprint 42.

However, today (Thu, Oct 17, 2019), I installed PostgreSQL 12 (using the C
locale) on my Windows 10 machine and was confronted with this very same
issue in pgAdmin v4.13.

In addition to the reported error message popup, right-clicking on a
database node does not show the custom context menu for the database node,
but the standard browser context menu, which I consider to be very
annoying.

The console of the browser developer tools shows some warnings in vendor.js
("unreachable code after return statement", "sprintf() will be removed in
the next major release, use the sprintf-js package instead").

I already attempted to reinstall PostgreSQL 12 and pgAdmin 4.13, but with no
success. Up to yesterday, my pgAdmin 4.13 installation worked perfectly fine
with PostgreSQL 11. (Except for the fact that my SQL Query tabs scroll to
the top after switching between them, but that's another issue. Perhaps I
will file a report for that bug as well.)

When using another PostgreSQL client (HeidiSQL), I get no issues or error
messages. But then again, in HeidiSQL, I have to explicitly connect to a
specific PostgreSQL database and after establishing a connection to the
database, I cannot easily switch to another database in that connection.
Also, HeidiSQL seems to interpret schemas as databases. So HeidiSQL is no
interesting alternative to me.