Does the issue still occur if you start Firefox in Safe Mode? http://support.mozilla.com/en-US/kb/Safe+Mode How about with a new, empty profile? http://support.mozilla.com/en-US/kb/Basic+Troubleshooting#Make_a_new_profile
Safe mode has the same issue, in 3.6.11 and .12. The new profile also has the same issue, as does a new installation on a fresh PC. 3.6.10 works fine as a new install. I've also discovered another anomaly with 3.6.11/.12, likely related, in that the book cart functionality doesn't work. (Find a single book title, click "Add to Book Bag," click "View My Book Bag" and "Export My Save Titles." This doesn't require a login, but Firefox shows "You have not saved any records for export." This does work in IE and Safari.
Are you seeing any errors in the error console when logging in or using the book bag function?
The website gives "server does not support RFC 5746" errror. With signon.debug set to true, when I try to log on I get this sequence: 1. Login Manager: observer notified for form submission. 2. Login Manager: Checking if logins to https://marinet.lib.ca.us can be saved. 3. PwMgr mozStorage: Getting login saving is enabled for https://marinet.lib.ca.us 4. Login Manager: (form submission ignored -- saving is disabled for: https://marinet.lib.ca.us) 5. marinet.lib.ca.us : server does not support RFC 5746, see CVE-2009-3555 6. Login Manager: onStateChange accepted: req = https://marinet.lib.ca.us/patroninfo~S3/1231405/top, flags = 0x30004 7. Login Manager: domEventListener: got event DOMContentLoaded 8. Login Manager: Counting logins matching host: https://marinet.lib.ca.us, formSubmitURL: , httpRealm: null 9. PwMgr mozStorage: _countLogins: counted logins: 0 No. 6 looks like the URL I should have if I logged in succesfully. When I click to add a book to the book bag, I get these: 1. Login Manager: onStateChange accepted: req = http://marinet.lib.ca.us/search~S3?/tempire/tempire/1,160,278,B/frameset&FF=tempire&5,,10?save=b1620521, flags = 0x30004 2. Login Manager: domEventListener: got event DOMContentLoaded 3. Login Manager: Counting logins matching host: http://marinet.lib.ca.us, formSubmitURL: , httpRealm: null 4. PwMgr mozStorage: _countLogins: counted logins: 0 None of it looks unusual, compared to a 3.6.10 session that does work. I did find a Firefox Help Forum report identical to our issues, at http://support.mozilla.com/en-US/questions/763100.
Do you have access to server logs that will show the requests coming in on the server? I am seeing the issue in Firefox and working in other browsers. Looking at the URL's that the JS calls are using they are identical in all browsers. I am curious if the server is receiving the correct info. Tyler -> Any ideas?
Kicking over to core. https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20status1.9.2%3A.11-fixed is the 3.6.11 changelist, if this happened in that update, has to be fallout from one of these bugs.
Component: General → General
Product: Firefox → Core
QA Contact: general → general
Version: 3.6 Branch → 1.9.2 Branch
Here's a sequence from the server logs as I tried to log in from my own PC. Patroninfo is the login screen, and there are 2 redirects, which might be where it's losing Firefox, but the final line shows the page as being sent frojm the server with a status 200. [21/Oct/2010:08:03:19 -0700] "GET /patroninfo HTTP/1.1" 301 117 "http://marinet.lib.ca.us/" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20101012 Firefox/3.6.11 (.NET CLR 3.5.30729)" 3087 [21/Oct/2010:08:03:20 -0700] "GET /patroninfo HTTP/1.1" 200 1997 "http://marinet.lib.ca.us/" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20101012 Firefox/3.6.11 (.NET CLR 3.5.30729)" 17394 [21/Oct/2010:08:03:23 -0700] "POST /patroninfo HTTP/1.1" 302 26 "https://marinet.lib.ca.us/patroninfo" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20101012 Firefox/3.6.11 (.NET CLR 3.5.30729)" 46178 [21/Oct/2010:08:03:23 -0700] "GET /patroninfo~S3/1231405/top HTTP/1.1" 200 1997 "https://marinet.lib.ca.us/patroninfo" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20101012 Firefox/3.6.11 (.NET CLR 3.5.30729)" 17230 [21/Oct/2010:08:03:27 -0700] "POST /patroninfo~S3/1231405/top HTTP/1.1" 302 26 "https://marinet.lib.ca.us/patroninfo~S3/1231405/top" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20101012 Firefox/3.6.11 (.NET CLR 3.5.30729)" 38892 [21/Oct/2010:08:03:27 -0700] "GET /patroninfo~S3/1231405/top HTTP/1.1" 200 1997 "https://marinet.lib.ca.us/patroninfo~S3/1231405/top" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20101012 Firefox/3.6.11 (.NET CLR 3.5.30729)" 17361
Works: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124pre) Gecko/20100928 Firefox/3.6.11pre ( .NET CLR 3.5.30729; .NET4.0E) ID:20100928042306 Fails: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199pre) Gecko/20100929 Firefox/3.6.11pre ( .NET CLR 3.5.30729; .NET4.0E) ID:20100929042157 Pushlog -> http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=+2010-09-28&enddate=2010-09-29
Our server vendor made an adjustment (adding an option to not "force cookies" whatever that means) and our problems have disappeared. They said that they had a second customer run into this issue, and so they figured out how to adapt the Apache server to the new security configuration of 3.6.11/3.5.14 and newer, which is probably the best outcome.
I think this might have the same cause as Bug 614565 - changing component to match that bug. Not sure if the fix in Bug 614565 will fix this so not marking as a duplicate yet. Gerv?
Component: General → Networking: Domain Lists
Keywords: regressionwindow-wanted → regression
QA Contact: general → networking.domain-lists
Tim: in comment 8, you link to a mozilla-central pushlog list. Surely you meant to link to a mozilla-1.9.2 list? https://hg.mozilla.org/releases/mozilla-1.9.2/pushloghtml?startdate=+2010-09-28&enddate=2010-09-29 That does include the PSL change in question. All of the site in question seems to be on marinet.lib.ca.us, and setting cookies for that should be fine. (Which is probably how they've got it to work now.) If the site was setting cookies for all of lib.ca.us before, that was probably the wrong thing... Dan: is the signon in your application designed to work across all California's public libraries, or just for your site? Also, are you happy with the fix your server vendor has produced, or are you pushing for more action from us? Gerv
Status: UNCONFIRMED → NEW
Ever confirmed: true
The signon is supposed to work only for our site, marinet.lib.ca.us. I'm happy with the vendor fix, though we've found some other odd behavior as a result of whatever they did. Some of our proxy-server database authentications aren't working in Firefox, giving an error page. ("The page isn't redirecting properly" error. Firefox has detected that the server is redirecting the request for this address in a way that will never complete. This problem can sometimes be caused by disabling or refusing to accept cookies.")
Summary: Login to site fails, login form clears on submit → Login to marinet.lib.ca.us fails, login form clears on submit
Resolving based on comment 12. Gerv
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Dan: setting cookies for the site marinet.lib.ca.us should work. If I click "Submit" on https://marinet.lib.ca.us/patroninfo, I see the following (from Firebug): Set-Cookie SESSION_SCOPE=3; path=/ III_EXPT_FILE=aa21953; path=/; domain=.lib.ca.us; path=/ III_SESSION_ID=129f63c181c47d427996ebd810ce9e0f; domain=.lib.ca.us; path=/ This is your problem. Your application is attempting to set cookies for all of the lib.ca.us domain. Get your vendor to stop doing that, and set them only for the domain marinet.lib.ca.us, and your logins will work again. Feel free to point them at this bug. Gerv
We're finally fixed. Thanks very much for pointing me in the right direction, I was able to use this information with our ILS vendor. (They only took 4 weeks to verify it and suggest a solution.) Our vendor's web software for some reason couldn't generate a cookie that would work with a domain name as short as ours (marinet.lib.ca.us), and all their other customers in .lib.ca.us had one more qualifier than we did so "no one else has this problem." Our solution was to alias our catalog to catalog.marinet.lib.ca.us, get a new security certificate including that, and we are now using session cookies and enjoying it in all browsers. Again, many thanks for your expertise.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago → 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.