ChatCraft week 13: Fixing bugs

This week on is the issue I created which outlines how to recreate the 4 bugs I found.

Bug 1

The first bug involved the Instructions page. This page is no longer in use for the most part, but will still come up when the user clears their current provider's api key.

Bug 2

The second bug is also on the Instructions page. The previous behaviour was that when we toggle between the providers in the dropdown, if one of them had a saved api key (from localStorage), then we set that key to settings.currentProvider. This poses a problem, since we are bypassing the key validation code and taking the user away from the Instructions page (Instructions page only shows up for users when the settings.currentProvider api key is blank, and it's no longer blank so we leave). The stored api key could be a stored key that is invalid. Or, the stored key could have become invalid after time passed.

I fixed this by introducing a state variable selectedProvider in

Bug 3

The third bug involves the User Settings modal. When the user enters a blank or invalid key we get a form error message as expected. However, when we close the modal and reopen it, that message is still there. There is also strange behaviour where if the user input a correct key into that field, the form error message still persists.

Bug 4

The last bug was brought to my attention while Yumei was testing my PR. I quickly found a fix so I just added it.

The bug involves browsers' password saving ability. When users enter an api key in Instructions page or when they create a custom provider, they were prompted by their browser whether they want to save the password. Users who have a key saved in their browser will experience a bug. The moment they clear their api key the browser will sense that the field is empty and repopulated it with their saved password. Also, when we create one or more providers with the same api url, it will indiscriminately populate the key for those providers.

I don't have a fix for users who have already saved an api key as their password, but I can stop ChatCraft from prompting users to save future keys as passwords. This took a bit of digging online, because many online solutions don't actually work. A lot of the time the browsers will not listen even if you set autoComplete="off". I tried many online solutions one by one, and finally found one that worked.

I found that when is set to password that is when the browsers will prompt the saving of the password. Therefore I changed it to always be text. Now I lost a feature of component, which used to use type = "password" to disguise the user key with asterix. However I was able to find a different way to hide the user key with asterix (see below!)

for these bug fixes was reviewed by three contributors and landed in release