The post has been massively overhauled to correct old information with newly discovered data.
Description of the issue:
For some reason directly visiting a URL that contains special characters after a browser restart via a URL paste, bookmark, history, link, etc, renders portions of an entire site completely unusable unless you restart the browser and navigate to that page manually using links on the web site’s home page first. If you try to directly access the link after opening Brave when it’s fully closed or after restarting it, Brave will modify something and cause 400 errors which can cripple the use of entire websites. This behavior persists even when clicking links that should work, such as “sign in”, until you restart the browser.
How can this issue be reproduced?
- Restart Brave, then visit https://lightsail.aws.amazon.com/ls/webapp/us-east-2/instances/TeleTab_2.0/connect?# in either desktop or mobile mode. It doesn’t matter which. It’s a link I use to directly connect to my VPS console. It should lead to a login page if it works.
- If that loads a 400 error, Brave broke it.
- Sometimes it might work as intended and send you to the login. If it does just close the tab, close (swipe it out of recent apps) Brave, relaunch Brave, and revisit that URL (I do it through a bookmark). You’ll get the 400 error.
The next part of this bug is that whatever Brave did to break that page will persist across the entire affected site, in this case AWS pages requiring a login, and completely break it. It can be observed by continuing below:
- Press the AWS logo in the top left to be taken to the main page.
- In the top right, press “Sign in”.
- This should lead to another 400 error. Again, this will persist across any part of the site that requires a login until Brave is restarted. Restarting fixes the persisting 400 error unless you visit the link I provided again, which will cause it to return.
To prove that this is in fact an issue with Brave and special characters in the URL, and not AWS’ fault, the following steps show that the link is valid and AWS is properly handling it.
- Restart Brave, then visit aws.amazon.com in desktop mode to simplify things.
- Click “sign in” in the top right if in desktop mode.
- When the login page shows, close the tab. This probably eliminates some variables for the next step. The next step will still work if done in the current tab.
- Open a new tab, then visit the link I provided in step 1 with the special characters in it. https://lightsail.aws.amazon.com/ls/webapp/us-east-2/instances/TeleTab_2.0/connect?#
- The link will correctly redirect to the login page no matter how you open it be it bookmark, link click, URL paste, etc. This proves the link is valid and working. It will now work every time no matter how you open it. But if you close the tab and restart Brave, then try to visit the link again, the entirety of AWS will once again be broken with 400 errors.
This places all blame on Brave and not AWS.
Prior to modifying this post, someone mentioned they were sent to a similar looking URL that correctly lead to the login page. I tried to reproduce the bug with that link and indeed could not get it to trigger until I finally tried again using the bookmark that includes my server name in the URL. Thus the link has been updated to include it, and the post updated with fresh information.
Steps 7-11 are how the browser should behave, except I shouldn’t be required to do that in order to get into my VPS console. The link should be able to be opened directly after a fresh browser start without breaking the entire site.
Brave Version( check
1.32.106, but it’s been happening for a long time now.
Mobile Device details
Samsung Galaxy Note 20 Ultra on Android 11.
The new link that includes my server name does work as intended in Firefox. It’s not invalid. If I’m already logged in I can visit that link without failure and always be sent right into my VPS console with it. But when I first launch the browser, because I need to quickly access the VPS I have it bookmarked, it’ll trash the entire site with the error 400 bug unless I perform steps 7-11 first. I think it’s the special characters doing it, so really it affects any link with special characters in it if that’s the case.
Here’s a video of the behavior. Between keeping the file size small enough to upload here, the quality legible enough to read, and editing the extra details out, the best solution was to just do a crude edit straight from my phone gallery to cover up sensitive information. That’s what the purple spots are. Editing them to only appear when they’re needed made the file size way too big. Seriously guys, 4 MB is way too small.