User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0 Not sure where to enter this bug, please move the appropriate component/category. Thanks. Reproducible: Always Steps to Reproduce: 1. Launch Firefox. 2. Open the QA Companion dialog. (Tools | QA Companion) 3. Click the Login to Litmus dialog's Cancel or Close (i.e. - red X) button. Actual Results: The Login to Litmus dialog will momentarily close & then re-open informing you that you entered incorrect login information & ask you to enter your login information again. Expected Results: The Login to Litmus dialog would close & QA Companion dialog would remain open although I would not have access to all of its functionality. The was prompted for & installed latest version of the QA Companion on 05/18/08 I didn't try accessing the QA Companion dialog until this morning (05/19/08).
Component: General → QA Companion
Product: Firefox → Other Applications
QA Contact: general → qa-companion
Yeah, this is just me taking a short cut, as we had to get the new version out and usable before the test day last week. As I only had a few hours I opted to treat the "Cancel" the same as "invalid login". This actually uncovers a larger problem in the extension though, since I don't think there is currently a way to make that login dialog happen on command. So, even if there was a way to disable entire selections (i.e. the Litmus tab if you're not logged in) there is no way to throw the "I'm logged in now" event and re-enable them. So, this is a pretty decent sized architectural issue in the extension. It is entirely solvable, it's just a fairly big set of changes that need to be made. Here are the changes: * Create a mechanism to Enable/Disable the controls (can we just disable wholesale tabs? (i.e. prevent people from clicking on disabled tabs?) * Create a reliable way to cause a log in dialog. The most obvious way to do this is the settings tab, and have the create/update button NOT assume that you are creating an account. Probably some XUL work there plus some JS back end as well. (Once you start the login process, it should probably call back into the qaMain object and call the correctCredentials function to ensure the valid login is stored. I'm pretty busy these days. The QAC is definitely taking patches, and I'm happy to review them. ;-)
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
I just got prompted to install version 1.14 of the QA Companion. The issue still exists but at least I now know that I originally have 1.13 on my machine when I entered the bug.
Created attachment 324684 [details] [diff] [review] patch to allow users to cancel the dialog This patch simply allows the user to cancel the login dialog. There are some other issues here that need some thinking (what should that button on the settings tab do if you already have an account, and why doesn't it ever remember your credentials on firefox 2?). But at least it fixes this terrible problem.
Assignee: nobody → ctalbert
Status: NEW → ASSIGNED
Attachment #324684 - Flags: review?(jay)
Comment on attachment 324684 [details] [diff] [review] patch to allow users to cancel the dialog r=jay, let's get this annoying bug fixed! Thanks Clint.
Attachment #324684 - Flags: review?(jay) → review+
Fix checked in into CVS for this and a version bump to 0.1.15. We need to decide what to do about CVS vs. Hg for this component. Filing a follow-on bug for that as this change will have to be up-merged into Hg. --> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.