Closed Bug 401096 Opened 18 years ago Closed 18 years ago

Login to Litmus via QAX does not work

Categories

(Other Applications Graveyard :: QA Companion, defect, P1)

Product:
Other Applications Graveyard
Component:
QA Companion
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: cbook, Assigned: cmtalbert)

Details

Attachments

(1 file, 1 obsolete file)

Fix for this that works on branch and trunk
6.75 KB, patch
jay
: review+
Details | Diff | Splinter Review
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.9pre) Gecko/2007102503 BonEcho/2.0.0.9pre and QAX 0.1.5 Credits go to jcea for finding this bug. When i use in QAX the Setup wizard to Login into my Litmus account, i get in QAX a login error. When i use the same data to login in litmus via the http://litmus.mozilla.org i have no problem. So its a Problem in QAX.
A trivial bug (seems so) in the QA extension... Ug! :-p
xp , Firefox 2.0.0.9 i'm also having the same problem , also tried to reset the password through litmus.mozzila.org , and it still don't work
If we want this extension/tool to be adopted, we really should fix this ASAP; we're seeing increasing reports of this, as new folks are trying it out.
setting to major, since more people are interested to help qa because of Firefox 3 they run into this bug, see also comment #3 from stephen.
Severity: normal → major
guys please help to me to find the source code of this extension , i can help with the debugging , but i'm a real newbie with all this open source working procedures , so please just show me the way. thanks
Working on it... Igor: thanks for your interest. The source code is in Mozilla's CVS repository under /mozilla/testing/extensions. I'll try to write up some directions on how to set up a development environment for the extension too.
Status: NEW → ASSIGNED
(In reply to comment #5) > guys please help to me to find the source code of this extension , i can help > with the debugging , but i'm a real newbie with all this open source working > procedures , so please just show me the way. > thanks > Igor, the code lives here: mozilla/testing/extensions/community/ Any help we can get is very appreciated. Ping us in IRC on # qa if you have questions.
Marking blocker and setting to P1. We need this basic functionality working before we "release" the QAX on AMO.
Severity: major → blocker
Priority: -- → P1
I have this problem under Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3pre) Gecko/2007122005 Firefox/3.0b3pre & QAX 0.1.5
Cc'ing Coop in case he can help us shed some light on this one. I wonder if he made changes to the Litmus website/apis that broke this. Coop: Can you take a look at the QAX code to see if we need to make some tweaks to work with the current version of Litmus?
I'm checking mxr/bonsai now, but I don't recall making changes that could have affected this. Of course, if the window really does extend back to Oct, that does improve the odds that something has changed. FWIW, I can't login either with QAX 0.1.5, but I've changed my password recently and the extension doesn't seen to have the ability to change my existing login credentials. Am I missing something here?
Assignee: zach → ccooper
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
(In reply to comment #11) > I'm checking mxr/bonsai now, but I don't recall making changes that could have > affected this. Of course, if the window really does extend back to Oct, that > does improve the odds that something has changed. Yeah, this has been around for long enough that it's worth a look. > > FWIW, I can't login either with QAX 0.1.5, but I've changed my password > recently and the extension doesn't seen to have the ability to change my > existing login credentials. Am I missing something here? > That is a good catch, I think the Litmus Settings form might be allow you to update your login info, but the button is misleading. I will check with Zach or Clint to confirm that. If you can't change credentials, we will need to add that feature before ship. I'll log a bug if needed. Thanks for looking into this Coop!
Found the problem. We switched to using SSL around that time, and all the references in the extension point to http:// URLs instead of https://. I unpacked the extension locally and changed the URLs and I was able to login successfully. I've put an updated XPI in my people.m.o account: http://people.mozilla.com/~coop/latest_QAX.xpi Someone with access (ctalbert,zach?) should review my work and then move the new XPI to the right dir if it's OK.
Assignee: ccooper → zach
Status: ASSIGNED → NEW
The extension is hosted out of ctalbert's people account, so I may as well just assign this to him.
Assignee: zach → ctalbert
Awesome Coop! Clint said he'll take it from here.
Attached patch Coop's changes (obsolete) — — Splinter Review
Patch containing changes for using https
Attachment #297654 - Flags: review?(zach)
Comment on attachment 297654 [details] [diff] [review] Coop's changes Canceling review. Looks like this only works on branch. There is something else wierd keeping us from working on trunk.
Attachment #297654 - Flags: review?(zach)
Thanks for figuring this out Coop. I was baffled on what could be causing this. I'll take a look later tonight at what else is going on with trunk that's keeping this from working.
Guys, I've got this debugged down to here: content/prefs.js line 178: this.manager().addLogin(newLogin) http://mxr.mozilla.org/mozilla/source/testing/extensions/community/chrome/content/prefs.js#178 here's what I see that is going on. The user selects that they have an existing litmus account. They enter correct username/password and click Next. We make the call thru JSON to litmus, we get back a 1, and we decide to set the password information in the prefs [1]. But, when setting that password information, we hit this line above and we throw. Mochikit catches an error with a code of 285. Zach, any ideas as to why that would throw on trunk and not branch? Do you know what error code 285 means? [1]: http://mxr.mozilla.org/mozilla/source/testing/extensions/community/chrome/content/settings.js#210
Figured out that the reason for this was that nsILoginManager no longer likes "null" for username and password fields. This gets us working on both branch and Linux. I also fixed the setup.xul so that the radio buttons work with keyboard access (orignally they only had an onclick handler and it was bugging me).
Attachment #297654 - Attachment is obsolete: true
Attachment #297828 - Flags: review?(zach)
Comment on attachment 297828 [details] [diff] [review] Fix for this that works on branch and trunk This looks good too, and it worked in your latest version on people. Let's get this in also. Thanks Clint!
Attachment #297828 - Flags: review?(zach) → review+
Fix checked in on trunk
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Version 0.1.6 (http://people.mozilla.com/~ctalbert/QAX/0.1.6.QAX.xpi) logs in on the following browsers: Trunk: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2008012404 Minefield/3.0b3pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008012404 Minefield/3.0b3pre -and- Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3pre) Gecko/2008012404 Minefield/3.0b3pre ----------------------------------------------------------------------------- Branch: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 -and- Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Status: RESOLVED → VERIFIED
OS: Linux → All
Hardware: PC → All
A week passed and no automatic update for guys with version 0.1.5 installed, like me :-).
(In reply to comment #24) > A week passed and no automatic update for guys with version 0.1.5 installed, > like me :-). > If you installed the extension from people.mozilla.org/~ctalbert/QAX, then click on "Find Updates" in the Add-Ons manager. It should find the update. If it does not find the update, then please file a bug on this. If you did not install from the above location, then uninstall this add-on and install the 0.1.6 version from that location. Let me know if you have any other problems.
I don't know where I install the extension from, originally. I installed the new XPI by hand. It works. Does it works in Firefox 3?.
Yes, I believe the updating works in FFx 3, and I know that the extension does.
"Mozilla Quality Extension 0.1.6 could not be installed because it is not compatible with Minefield 3.0b4pre". Since this extension is used by QA, keeping it updated to last FF nightly builds may be a good idea :-).
That's what Nightly Tester tools is for. Then disable add-on compatability checking. That's what I do.
Why don't we just update the install.rdf file to allow a maxVersion of 3.* and never have to worry about it again? AFAIK there's nothing in the extension that is going to break compatibility-wise in the 3.* timeframe.
Coop: See my patch for bug 393440. :-) Do you know if AMO supports wildcard maxversions? If it does, we'll just leave it at 3.0.* when we push it live there.
Product: Webtools → Other Applications
Version: Trunk → unspecified
Product: Other Applications → Other Applications Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: