Roundcube 1.1.0 & 1.2.0 can't handle URLs with Authentication in Firefox

[daniel-mueller-3w-media-de]

Commit b2992dd introduced a subtle bug: If you open Roundcube via an URL of the form http://user:[email protected]/roundcube/ (or https:// instead of http://) and log in, Roundcube versions that contain the stated commit (seem to be all version of the 1.1 and the 1.2 branch, but none of the 1.0 branch) will then show the "Loading..." spinner endlessly when accessing the Inbox. Switching to a different folder and then switching back will not remedy the problem, but it only affects the Inbox, other folders are displayed as usual, i.e. almost instantly. Changing the skin to classic does not help, but visiting the same URL again by clicking Firefox's address bar and hitting enter does help (i.e. the "Loading..." disappears and the problem does not occur again until the next login). Removing the username & password from the URL solves the problem, but note that this does not have anything to do with HTTP basic authentication. The username & password were prepended to the URL in my tests, but were not actually used for authentication. The form of the URL alone seems to trigger the bug.

Tested with Firefox 31.8 in Debian 7, Firefox 48 in Windows 7 and Firefox 45.0.1 on Android 4.4.4 (I also tested with Google Chrome, which was not affected). Roundcube was used without plugins and Roundcubes error logs don't contain any hints (not that I expected them to do so - it seems to be a Javascript issue).

[alecpl]

Confirmed. It looks like the problem is in window.history.replaceState() call. This causes "SecurityError: The operation is insecure." error. Because of this any code after the error is not executed, but some variables are expected to exist when the request returns, so parsing the response fails with javascript error.

One solution I found would be to use setTimeout(). This does not really fix the security error, but does not stop code execution. I tried setting the full url for replaceState() but this didn't work.

[alecpl]

@thomascube what do you think? Do we need this code at all?

[alecpl]

Fixed with try/catch.