[Bug 77859] Re: Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin
I've retitled the bug to make it clearer that (a) it's a regression, (b) it only affects Ubuntu Dapper, and (c) it's only the Firefox 1.5.0.9 security update which is affected. At this point I don't think we need any more "it doesn't crash for me, but I'm using some other browser version" reports. It's pretty clearly a flaw introduced with the security update and as far as I can tell affects everyone using Ubuntu Dapper with Firefox 1.5.0.9 and an affected webpage (password only form with saved passwords). Ewens ** Summary changed: - Saved passwords causes crash with Mailman admin (1.5.x) + Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin ** Description changed: Binary package hint: firefox + + [Edit: NOTE: This is a _regression_ in Firefox 1.5.0.9, released as a + security update for Ubuntu Dapper. Functionality that used to work + perfectly now causes the browser to crash hard. The problem appears to + be widely reproduced with the only people unable to reproduce it being + those using some other browser version.] The latest security update for Firefox for Ubuntu Dapper (6.06), version 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, now causes Firefox to crash repeatedly when using a saved password field on a Mailman admin login screen. This did not happen with the previous version (1.5.dfsg+1.5.0.8-0ubuntu0.6.06) or any previous version that I can recall. Other forms with saved passwords may also be affected (I initially thought that it was all saved forms, but it seems the one for launchpad.net isn't affected -- curious). Ubuntu Version: Dapper Drake (6.06) Firefox Version: 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, Reproducable: always How to reproduce: 1. Stop Firefox 2. Remove ~/.mozilla/firefox/PROFILE/signons.txt 3. Start Firefox 4. Go to http://somelistserver/mailman/admindb/mailman 5. Log in 6. Choose to allow Firefox to save the password 7. Observe Firefox crashes 8. Restart Firefox 9. Go back to http://somelistserver/mailman/admindb/mailman 10. Observe Firefox crashes again without displaying the page 11. Go back to step 2 and repeat. 12. Go back to step 2 and repeat choosing NOT to save the password at step 6 and observe Firefox doesn't crash Desired behaviour: As per previous version, should fill in saved password for the form and not crash. Other notes: It doesn't appear necessary for the password to actually be correct; just that it be saved. The crash on visiting the page with a saved password appears to happen aroun the time that the saved password might be pre-filled. Completely removing the saved passwords and starting again doesn't seem to help; as soon as the password is saved the problem reappears. Removing the firefox profile and starting again also doesn't seem to help; again as soon as the password is saved the problem reappears. The only thing I can see which is noticably different between the Mailman login page and, eg, the launchpad.net login page, in terms of saved passwords, is that the Mailman page is password-only, whereas the launchpad.net has an email address as well as the password. Possibly the bug is somehow related to the form being password-only. This behaviour is new with the security update for Ubuntu Dapper which came out this morning. I've used the saved password feature with many previous versions of Firefox without any problems. Knowing the issues which have been reported with Firefox recently, including a password stealing attack, I'd guess that there is a bug in the "fix" chosen to try to defeat that password stealing attack. Finally, for what little it seems to be worth, a backtrace of the coredump: [EMAIL PROTECTED]:/var/tmp$ gdb /usr/lib/firefox/firefox-bin core.10049 GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) Core was generated by `/usr/lib/firefox/firefox-bin -a firefox'. Program terminated with signal 11, Segmentation fault. [] #0 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7e56790 in raise () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x08055e0b in ?? () #3 0x000b in ?? () #4 0xbfaf0e8c in ?? () #5 0x in ?? () (gdb) Ewen -- Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.
[Bug 77859] Patch for Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin
I've now modified the patch from Mozilla Bugzilla (linked earlier in this bug) to apply to Firefox 1.5.0.9 (as shipped with Ubuntu) and recompiled the Firefox package with the patch (which takes about 2 hours, and 1GB of disk space), and appear to have a non-broken version of Firefox that is able to handled saved passwords on forms with and without usernames (ie, properly fill them in, both Mailman's admin screen and Launchpad's login form seemed to work). The modified patch is attached. Perhaps someone at Ubuntu could verify that this patch makes sense, and if so apply it and rebuild the Firefox security update. (I'd offer to make my binary available for others to test, but as far as I can tell Firefox trademark restrictions prevent anyone distributing a non- authorised build, even if it's supposed to be more stable than the one it replaces.) Ewen ** Attachment added: "Firefox 1.5.0.9 password only forms fix" http://librarian.launchpad.net/5859913/firefox-1.5.0.9-saved-passwords-password-only.diff -- Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin
I can confirm that the Firefox package 1.5.dfsg+1.5.0.9-0ubuntu0.6.06.1 no longer crashes when presented with the Mailman admin form where there is a saved password. Thanks for pushing out updated packages. Ewen -- Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Firefox: saved passwords causes crash with Mailman admin page
Public bug reported: Binary package hint: firefox The latest security update for Firefox for Ubuntu Dapper (6.06), version 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, now causes Firefox to crash repeatedly when using a saved password field on a Mailman admin login screen. This did not happen with the previous version (1.5.dfsg+1.5.0.8-0ubuntu0.6.06) or any previous version that I can recall. Other forms with saved passwords may also be affected (I initially thought that it was all saved forms, but it seems the one for launchpad.net isn't affected -- curious). Ubuntu Version: Dapper Drake (6.06) Firefox Version: 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, Reproducable: always How to reproduce: 1. Stop Firefox 2. Remove ~/.mozilla/firefox/PROFILE/signons.txt 3. Start Firefox 4. Go to http://somelistserver/mailman/admindb/mailman 5. Log in 6. Choose to allow Firefox to save the password 7. Observe Firefox crashes 8. Restart Firefox 9. Go back to http://somelistserver/mailman/admindb/mailman 10. Observe Firefox crashes again without displaying the page 11. Go back to step 2 and repeat. 12. Go back to step 2 and repeat choosing NOT to save the password at step 6 and observe Firefox doesn't crash Desired behaviour: As per previous version, should fill in saved password for the form and not crash. Other notes: It doesn't appear necessary for the password to actually be correct; just that it be saved. The crash on visiting the page with a saved password appears to happen aroun the time that the saved password might be pre-filled. Completely removing the saved passwords and starting again doesn't seem to help; as soon as the password is saved the problem reappears. Removing the firefox profile and starting again also doesn't seem to help; again as soon as the password is saved the problem reappears. The only thing I can see which is noticably different between the Mailman login page and, eg, the launchpad.net login page, in terms of saved passwords, is that the Mailman page is password-only, whereas the launchpad.net has an email address as well as the password. Possibly the bug is somehow related to the form being password-only. This behaviour is new with the security update for Ubuntu Dapper which came out this morning. I've used the saved password feature with many previous versions of Firefox without any problems. Knowing the issues which have been reported with Firefox recently, including a password stealing attack, I'd guess that there is a bug in the "fix" chosen to try to defeat that password stealing attack. Finally, for what little it seems to be worth, a backtrace of the coredump: [EMAIL PROTECTED]:/var/tmp$ gdb /usr/lib/firefox/firefox-bin core.10049 GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) Core was generated by `/usr/lib/firefox/firefox-bin -a firefox'. Program terminated with signal 11, Segmentation fault. [] #0 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7e56790 in raise () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x08055e0b in ?? () #3 0x000b in ?? () #4 0xbfaf0e8c in ?? () #5 0x in ?? () (gdb) Ewen ** Affects: firefox (Ubuntu) Importance: Undecided Status: Unconfirmed -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
Issolated test case: http://www.naos.co.nz/tmp/ubuntu/firefox/mailman-signon-page.html Steps to reproduce is slightly different here, I think because there's no real form processing behind it. To reproduce: 1. Go to URL 2Enter some string to be the password, eg "test" (it doens't matter, just needs something) 3. Choose to remember the password 4. Observe "success" message 5. Go back to URL (eg, click on the link in the success page) 6. Observe browser crashes 7. Restart firefox 8. Go to URL 9. Observe browser crashes 10. Remove ~/.mozilla/firefox/PROFILE/signons.txt 11. Start firefox 12. Go to URL 13. Observe browser doesn't crash 14. Repeat from 2 Test case (stripped down version of the Mailman admin page) is attached. The "success" page is just a stub HTML page with a link to this bug and back to the test case for convenience. Something like the launchpad.net signon form can serve as an example that doesn't crash. Ewen ** Attachment added: "Issolated test case (extracted from Mailman admin signon form)" http://librarian.launchpad.net/5593238/mailman-signon-page.html -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
As suggested by Peter Cherriman (https://launchpad.net/~pjcherriman) in comment: https://launchpad.net/ubuntu/+source/firefox/+bug/77859/comments/3 I've installed the firefox-dbg package (ie, debug symbols), and regenerated the core dump and run gdb over it. Like him I see: nsPasswordManager::AttachToInput (this=0x89f6368, aElement=0x0) at nsPasswordManager.cpp:1962 as the topmost item on the stack prior to the signal handler being invoked, so I too suspect that aElement=0x0 is somehow involved in the segmentation fault. Full gdb backtrace follows. Ewen -=- cut here -=- [EMAIL PROTECTED]:/var/tmp$ ulimit -c unlimited [EMAIL PROTECTED]:/var/tmp$ firefox & [1] 26943 [EMAIL PROTECTED]:/var/tmp$ [1]+ Segmentation fault (core dumped) firefox [EMAIL PROTECTED]:/var/tmp$ ls -l core* -rw--- 1 ewen ewen 55312384 2007-01-06 12:38 core.26943 [EMAIL PROTECTED]:/var/tmp$ gdb /usr/lib/firefox/firefox-bin core.26943 GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/ lib/tls/i686/cmov/libthread_db.so.1". Core was generated by `/usr/lib/firefox/firefox-bin -a firefox'. Program terminated with signal 11, Segmentation fault. warning: Can't read pathname for load map: Input/output error. Reading symbols from /usr/lib/firefox/libmozjs.so...Reading symbols from /usr/li b/debug/usr/lib/firefox/libmozjs.so...done. done. [] Loaded symbols for /usr/lib/firefox/components/libnkgnomevfs.so #0 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7d8d790 in raise () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x08055e0b in nsProfileLock::FatalSignalHandler (signo=-1210510412) at nsProfileLock.cpp:206 #3 #4 0xb67e65cc in nsPasswordManager::AttachToInput (this=0x89f6368, aElement=0x0) at nsPasswordManager.cpp:1962 #5 0xb67e7724 in nsPasswordManager::OnStateChange (this=0x89f6368, aWebProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsPasswordManager.cpp:948 #6 0xb5dd3e62 in nsDocLoader::FireOnStateChange (this=0x8205c88, aProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsDocLoader.cpp:1210 #7 0xb5dd3ea0 in nsDocLoader::FireOnStateChange (this=0x835a5b8, aProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsDocLoader.cpp:1217 #8 0xb5dd3ea0 in nsDocLoader::FireOnStateChange (this=0x86a6cd8, aProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsDocLoader.cpp:1217 #9 0xb5dd423b in nsDocLoader::doStopDocumentLoad (this=0x86a6cd8, request=0x86939b4, aStatus=0) at nsDocLoader.cpp:833 #10 0xb5dd4313 in nsDocLoader::DocLoaderIsEmpty (this=0x86a6cd8) at nsDocLoader.cpp:739 #11 0xb5dd45df in nsDocLoader::OnStopRequest (this=0x86a6cd8, aRequest=0x890d118, aCtxt=0x0, aStatus=0) at nsDocLoader.cpp:662 #12 0xb723ae35 in nsLoadGroup::RemoveRequest (this=0x86a6740, request=0x890d118, ctxt=0x0, aStatus=0) at nsLoadGroup.cpp:732 #13 0xb56c0c6e in nsDocument::UnblockOnload (this=0x88ff600) at nsDocument.cpp:5015 #14 0xb56e256a in DestroyImagePLEvent (aEvent=0x8a09438) at nsImageLoadingContent.cpp:668 #15 0xb7e40351 in PL_DestroyEvent (self=0x8a09438) at plevent.c:727 #16 0xb7e403bd in PL_HandleEvent (self=0x8a09438) at plevent.c:699 #17 0xb7e40b2e in PL_ProcessPendingEvents (self=0x80d3758) at plevent.c:623 #18 0xb7e41ed0 in nsEventQueueImpl::ProcessPendingEvents (this=0x80d3710) at nsEventQueue.cpp:417 #19 0xb68a3449 in event_processor_callback (source=0x8312d28, condition=G_IO_IN, data=0x0) at nsAppShell.cpp:67 #20 0xb77bc52c in g_vasprintf () from /usr/lib/libglib-2.0.so.0 #21 0xb77958d6 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #22 0xb7798996 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #23 0xb7798cb8 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #24 0xb7bc7765 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #25 0xb68a38da in nsAppShell::Run (this=0x814e778) at nsAppShell.cpp:139 #26 0xb67c33d2 in nsAppStartup::Run (this=0x814e738) at nsAppStartup.cpp:150 #27 0x0804f321 in XRE_main (argc=3, argv=0xbf82acf4, aAppData=0x80595e0) at nsAppRunner.cpp:2380 #28 0x0804abe4 in main (argc=0, argv=0x0) at nsBrowserApp.cpp:61 #29 0xb752bea2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 #30 0x0804ab31 in _start () at ../sysdeps/i386/elf/start.S:119 (gdb) -=- cut here -=- -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
Source for affected function that is segfaulting: void nsPasswordManager::AttachToInput(nsIDOMHTMLInputElement* aElement) { nsCOMPtr targ = do_QueryInterface(aElement); nsIDOMEventListener* listener = NS_STATIC_CAST(nsIDOMFocusListener*, this); targ->AddEventListener(NS_LITERAL_STRING("blur"), listener, PR_FALSE); targ->AddEventListener(NS_LITERAL_STRING("DOMAutoComplete"), listener, PR_FALSE); mAutoCompleteInputs.Put(aElement, 1); } (1956-1966 in firefox-1.5.dfsg+1.5.0.9/toolkit/components/passwordmgr/base/nsPasswordManager.cpp) The affected line, 1962, is: targ->AddEventListener(NS_LITERAL_STRING("blur"), listener, PR_FALSE); and appears to be segfaulting because the raw pointer inside targ is 0x0: (gdb) print targ $1 = { = {mRawPtr = 0x0}, } I _think_ that the raw pointer inside targ is null because atElement is null, but there's too much magic in the ns smart pointers to trace through without ever having seen the code before. Working back up the stack, the caller is: -=- cut here -=- (gdb) up #5 0xb67e7724 in nsPasswordManager::OnStateChange (this=0x89f6368, aWebProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsPasswordManager.cpp:948 948 AttachToInput(userField); (gdb) print userField $6 = { = {mRawPtr = 0x0}, } (gdb) -=- cut here -=- where the function contains the inline comment: -=- cut here -=- // We can auto-prefill the username and password if there is only // one stored login that matches the username and password field names // on the form in question. Note that we only need to worry about a // single login per form. -=- cut here -=- All of which tends to confirm my impression that the problem is prefilling in a save password on forms which have only a password field and no username field, Whatever changed in the code appears to no longer properly handle the situation where there is no username field and instead seems to assume that there'll be a username field to attach to if it finds a password field When it tries to attach to a non-existantant username field, thus dereferencing the null, it crashes. Ewen -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
I managed to find the source to firefox-1.5.dfsg+1.5.0.8 on a mirror (http://mirror.xmu.edu.cn/archive.ubuntu.com/ubuntu/pool/main/f/firefox/; it's already expired out of security.ubuntu.com and archive.ubuntu.com). Diff between firefox-1.5.dfsg+1.5.0.8 and firefox-1.5.dfsg+1.5.0.9 reveals that a guard on userField being non-null was removed between those two versions, viz: -=- cut here -=- @@ -941,20 +945,20 @@ } if (firstMatch && !attachedToInput) { - nsAutoString buffer; - - if (userField) { + AttachToInput(userField); + + if (prefillForm) { +nsAutoString buffer; if (NS_FAILED(DecryptData(firstMatch->userValue, buffer))) goto done; -=- cut here -=- (Full diff of that file below.) So since it appears to be fatal to call AttachToInput(NULL), it appears that the function has been "deliberately" changed to cause Firefox to crash when faced with a presaved form which has no username field. This seems to be undesirable. At very worst it should refuse to fill in the form and continue running; ideally it would continue the previous Firefox behaviour and fill in the form without fuss. There's nothing in the comments or changelog to explain why the guard on userField being non-null was removed. The entire changelog for .8 to .9 is: -=- cut here -=- firefox (1.5.dfsg+1.5.0.9-0ubuntu0.6.06) dapper-security; urgency=low * New upstream security update: - CVE-2006-6504, MFSA 2006-73: SVG Processing Remote Code Execution. - CVE-2006-6503, MFSA 2006-72: XSS by setting img.src to javascript: URI. - CVE-2006-6502, MFSA 2006-71: LiveConnect crash finalizing JS objects. - CVE-2006-6501, MFSA 2006-70: Privilege escallation using watch point. - CVE-2006-6497, CVE-2006-6498, CVE-2006-6499, MFSA 2006-68: Crashes with evidence of memory corruption. -- Kees Cook <[EMAIL PROTECTED]> Tue, 2 Jan 2007 11:23:28 -0800 -=- cut here -=- None of the CVE or MFSA documents referenced talk about the password manager or saved password exploits or appear to explain why this code was changed. Given other security discussion I'm aware of I assume it's part of an attempt to avoid the recently publicised password stealing attack through user-created forms being pre-filled. The list appears to come from here: http://www.mozilla.org/projects/security/known- vulnerabilities.html#firefox1.5.0.9 which is referenced from here: http://www.mozilla.com/en-US/firefox/releases/1.5.0.9.html which is the upstream announcement of 1.5.0.9. Most of the change in nsPasswordManager.cpp appears to have come from upstream (comparing diffs with and without the ubuntu dapper patches). However upstream 1.5.0.8 upstream also didn't have the guard on userField being non-NULL. That guard was being added by the ubuntu dapper patch in 1.5.0.8, but is not being added in 1.5.0.9. In particular we seem to have lost this patch: -=- cut here -=- * toolkit/components/passwordmgr/base/nsPasswordManager.cpp: Take patch from bz#235336 as suggested by Ian Jackson to allow password manager to work with sites that only have a password field, no username. -- Eric Dorland <[EMAIL PROTECTED]> Mon, 6 Feb 2006 23:10:29 -0500 -=- cut here -=- I'm not sure what "bz#235336" is or where it can be found, but I strongly suspect that it includes the guard on userField being non-null. So it appears that a combination of an upstream change and dropping a patch that allowed password manager to work with password-only forms has caused this crash. It also appears to me that upstream will have this bug (crash with saved passwords on forms with only a password field) if I'm reading their code correctly. Any chance we can have this "bz#235336" patch reapplied and/or the guard on userField back again, so password manager works with password only forms and firefox doesn't crash? Ewen -=- full 1.5.0.8 to 1.5.0.9 diff for nsPasswordManager.cpp -=- [EMAIL PROTECTED]:/var/tmp/ubuntu-dapper-firefox$ diff -u firefox-1.5.dfsg+1.5.0.{8,9}/toolkit/components/passwordmgr/base/nsPasswordManager.cpp --- firefox-1.5.dfsg+1.5.0.8/toolkit/components/passwordmgr/base/nsPasswordManager.cpp 2007-01-06 13:45:37.0 +1300 +++ firefox-1.5.dfsg+1.5.0.9/toolkit/components/passwordmgr/base/nsPasswordManager.cpp 2007-01-06 12:53:22.0 +1300 @@ -815,6 +815,10 @@ PRUint32 formCount; forms->GetLength(&formCount); + + // check to see if we should formfill. failure is non-fatal + PRBool prefillForm = PR_TRUE; + mPrefBranch->GetBoolPref("prefillForms", &prefillForm); // We can auto-prefill the username and password if there is only // one stored login that matches the username and password field names @@ -907,7 +911,7 @@ continue; } - if (!oldUserValue.IsEmpty()) { + if (!oldUserValue.IsEmpty() && prefillForm) { // The page has prefilled a username. // If it matches any of our saved usernames, prefill the password
[Bug 77859] Firefox: Regression: saved passwords: password only forms crash firefox (patch lost)
Found the patch that got lost: Mozilla Bugzilla 235336: https://bugzilla.mozilla.org/show_bug.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&id=235336 (was obvious once I guessed that "bz" == "Bugzilla" not "Baz"/"Bazzar" or similar.) And the relevant patch: https://bugzilla.mozilla.org/attachment.cgi?id=185577 referred to does indeed add the guard on userField being non-NULL. Please apply, modified as necessary to fit 1.5.0.9. Ewen -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
In the hope that this will bring the bug to the firefox/security maintainers attention, I've changed the status to "confirmed" given (a) the number of bugs which have been marked as a duplicate of this bug, and (b) that several people have reported they can reproduce the bug. It would be nice to have some indication from the Firefox maintainer and/or the Ubuntu security folks as to when this regression introduced with the Dapper 1.5.0.9 package might be looked at. Ewen ** Changed in: firefox (Ubuntu) Status: Unconfirmed => Confirmed -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
lspci -vvnn on HP NC6220 laptop attached, as requested. ** Attachment added: "lspci -vvnn on HP NC6220" http://launchpadlibrarian.net/11928656/hp-nc6220-lspci-vvnn.txt -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
I've just attempted to reproduce it now, with the same results as you (ie, the DPMS off time isn't being set as it was previously). I wondered whether it had something to do with either s2ram, or adding a monitor on resume (eg, docking with an external monitor) but neither of those seem to be triggering it now. I'll keep an eye out for it happening again in the next couple of weeks (it's pretty obvious as the monitor starts turning off pretty soon after I stop typing), and if it does happen try to figure out a more precise sequence to get it into that situation. If I don't see it again, perhaps it got resolved by a recent update. Thanks for trying to reproduce it. Ewen -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
I think I've figured out how to trigger it. The computer in question is a laptop, with an external CRT connected via a docking station some of the time -- and all the times the DPMS Off: value has been incorrectly set, the laptop has been docked with the CRT connected. In order to trigger it I seem to need to: - boot up docked, with the CRT on - suspend to RAM - turn off the CRT - unsuspend (which is hit the power button in the case of this laptop) - while unsuspending, turn on the CRT (at the "right" time) In that situation I get: DPMS (Energy Star): Standby: 0Suspend: 0Off: 60 DPMS is Enabled Monitor is On or: DPMS (Energy Star): Standby: 0Suspend: 0Off: 300 DPMS is Enabled Monitor is On with the "Off:" time being set to the difference between the Power Mangement time and the Screensaver time. And if that time is non-zero, then playing with the adjusters seems to set the Off: time to the difference between the two (which definitely seems to be the wrong behaviour to me). So there appears to be two things going on: - there's something in Gnome (presumably Power Management) which is incorrectly setting the DPMS Off time to the difference between the Power Management off time and the Screensaver time (possibly when it notices a non-zero Off: time -- but irrespective, it's still doing the wrong thing: if it's going to set it, it should be to the total Power Management off time, or 0) - there's a race condition between the CRT waking up and the DPMS being reset to zero (possibly by some other power management program or task), where the DPMS setting doesn't "stick" until the CRT is ready to accept it (for which the fix is presumably to have the power management reapply the setting a little while, eg, 30 seconds, after either (a) unsuspend, or (b) the arrival of a new monitor. It appears once it becomes a non-zero value it's difficult to get the "reset to 0" behaviour back; I did manage it with one suspend (powering on the CRT a little earlier in the unsuspend), but other attempts still didn't reset it to zero (including ensuring the CRT was fully powered on before unsuspending). In case it matters, the laptop is a HP NC6220, which has Intel integrated graphics (Intel 915GM), with a HP docking station, and a Viewsonic E70 CRT connected to it. Anyway it seems to me that if the Gnome power manager is going to manage the display power off itself, it should probably be explicitly resetting the X DPMS Off: time (and others) to 0, and definitely never setting it to the difference between the screensaver time and the Power Management screen off time. That seems to be the core bug. Ewen -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
Resetting status to New since there is now (hopefully) a way for others to reproduce it. ** Changed in: gnome-power-manager (Ubuntu) Status: Invalid => New -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
** Description changed: Binary package hint: gnome-power-manager In Ubuntu Gutsy (7.10) with gnome-power-manager (2.20.0-0ubuntu6), the System->Preferences->Power Management slider for "Put display to sleep when inactive for" shows values that start with the value set in System->Preferences->Screensaver slider for "Regard the computer as idle after", and go upwards from there. Eg, if the Screensaver figure is set to 8 minutes, the minimum that the Power Manager display sleep can be - set to is 8 minutes. + set to is 9 minutes (8+1 minutes). However the value that is stored in the gnome configuration does not have this offset (eg, with the screensaver figure of 8 minutes, a power management display off figure of "13 minutes", the value stored in the gnome configuration will be 300 seconds (ie, 5 minutes). With a power management display off figure of "14 minutes" the value stored will be 360 seconds (ie, 6 minutes). The value from the gnome configuration is then applied as an X DPMS "power off" time, eg 300 seconds as the display time off. The result is that the monitor will then turn off after 5 minutes (300 seconds), even though the gnome power management display off time is reported through the user interface as "13 minutes". And thus the monitor turns off even before the screen saver kicks in, and much earlier than it was set to do so. The only combination that actually works sanely is to set both timeouts to the same value (0 minutes difference), which results in a DPMS off time of 0 seconds, which happens to disable the automatic X server DPMS off time (leaving gnome power manager to do its own thing). This effect (idle time shown = screen saver time + power manager time; from https://bugs.launchpad.net/ubuntu/+source/gnome-power- manager/+bug/135813/comments/5) would appear to explain this bug: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/59589 too (ie, why the value cannot be set below 11 minutes -- they presumably have a screensaver time of 11 minutes). Obviously I expect that the time specified in gnome power manager to power off the display will be the time in reality, not some arbitrarily shorter time. (I first noticed this with a screen saver time of 8 minutes, and a display off time of 9 minutes -- which caused the screen to power down after 1 minute of inactivity.) There are various ways this could be fixed to work sanely: - have gnome-power-manager not set the X server DPMS time and manage everything itself, counting from when the screen saver kicks in - have gnome-power-manager set the X server DPMS time to the value stored plus the screen saver timeout (so the overall time is consistent with what is shown in the preferences dialog) - have the preferences dialog store the value shown into the gnome preferences (including the amount that is attributed to the screensaver timeout, eg the full 13 minutes == 780 seconds) so that the value can be set directly into the X server DPMS and will give the correct timeout - decouple the power manager and screen saver timeouts again, so that the power manager screen off time can be set from 1 minute upwards. This would also allow having the screen powered down before the screen is locked, which can be useful if one is doing something else nearby but wants to save power (eg, a power manager off time of 3 minutes, and a lock time of 5 minutes, would power the display down pretty rapidly but allow waking it with a keypress without having to type in a password). This would just require changing the power manager preferences UI to accurately report the figure it's setting into the gnome preferences. Ewen ** Description changed: Binary package hint: gnome-power-manager In Ubuntu Gutsy (7.10) with gnome-power-manager (2.20.0-0ubuntu6), the System->Preferences->Power Management slider for "Put display to sleep when inactive for" shows values that start with the value set in System->Preferences->Screensaver slider for "Regard the computer as idle after", and go upwards from there. Eg, if the Screensaver figure is set to 8 minutes, the minimum that the Power Manager display sleep can be set to is 9 minutes (8+1 minutes). However the value that is stored in the gnome configuration does not have this offset (eg, with the screensaver figure of 8 minutes, a power management display off figure of "13 minutes", the value stored in the gnome configuration will be 300 seconds (ie, 5 minutes). With a power management display off figure of "14 minutes" the value stored will be 360 seconds (ie, 6 minutes). The value from the gnome configuration is then applied as an X DPMS "power off" time, eg 300 seconds as the display time off. The result is that the monitor will then turn off after 5 minutes (300 seconds), even though the gnome power management display off time
[Bug 59589] Re: display sleep time - why 11 minutes
I suspect the "11 minutes" minimum is coming from your system->preferences->screensaver being set to 11 minutes; the figure reported in the gnome power manager dialog seems to be offset by the screensaver amount (even though it doesn't seem to be implemented like that); I've reported a separate bug about this disparity between the UI and what actually happens: https://bugs.launchpad.net/ubuntu/+source/gnome-power- manager/+bug/190537 For now the best work around I can find is to set the gnome power manager display off timeout to be sufficiently large that the difference between that timeout and the screensaver timeout is the power off time that I actually want. Ewen -- display sleep time - why 11 minutes https://bugs.launchpad.net/bugs/59589 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] [NEW] [Gutsy] Display sleep sets wrong DPMS off time
Public bug reported: Binary package hint: gnome-power-manager In Ubuntu Gutsy (7.10) with gnome-power-manager (2.20.0-0ubuntu6), the System->Preferences->Power Management slider for "Put display to sleep when inactive for" shows values that start with the value set in System->Preferences->Screensaver slider for "Regard the computer as idle after", and go upwards from there. Eg, if the Screensaver figure is set to 8 minutes, the minimum that the Power Manager display sleep can be set to is 8 minutes. However the value that is stored in the gnome configuration does not have this offset (eg, with the screensaver figure of 8 minutes, a power management display off figure of "13 minutes", the value stored in the gnome configuration will be 300 seconds (ie, 5 minutes). With a power management display off figure of "14 minutes" the value stored will be 360 seconds (ie, 6 minutes). The value from the gnome configuration is then applied as an X DPMS "power off" time, eg 300 seconds as the display time off. The result is that the monitor will then turn off after 5 minutes (300 seconds), even though the gnome power management display off time is reported through the user interface as "13 minutes". And thus the monitor turns off even before the screen saver kicks in, and much earlier than it was set to do so. The only combination that actually works sanely is to set both timeouts to the same value (0 minutes difference), which results in a DPMS off time of 0 seconds, which happens to display the automatic X server DPMS off time (leaving gnome power manager to do its own thing). This effect (idle time shown = screen saver time + power manager time; from https://bugs.launchpad.net/ubuntu/+source/gnome-power- manager/+bug/135813/comments/5) would appear to explain this bug: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/59589 too (ie, why the value cannot be set below 11 minutes -- they presumably have a screensaver time of 11 minutes). Obviously I expect that the time specified in gnome power manager to power off the display will be the time in reality, not some arbitrarily shorter time. (I first noticed this with a screen saver time of 8 minutes, and a display off time of 9 minutes -- which caused the screen to power down after 1 minute of inactivity.) There are various ways this could be fixed to work sanely: - have gnome-power-manager not set the X server DPMS time and manage everything itself, counting from when the screen saver kicks in - have gnome-power-manager set the X server DPMS time to the value stored plus the screen saver timeout (so the overall time is consistent with what is shown in the preferences dialog) - have the preferences dialog store the value shown into the gnome preferences (including the amount that is attributed to the screensaver timeout, eg the full 13 minutes == 780 seconds) so that the value can be set directly into the X server DPMS and will give the correct timeout - decouple the power manager and screen saver timeouts again, so that the power manager screen off time can be set from 1 minute upwards. This would also allow having the screen powered down before the screen is locked, which can be useful if one is doing something else nearby but wants to save power (eg, a power manager off time of 3 minutes, and a lock time of 5 minutes, would power the display down pretty rapidly but allow waking it with a keypress without having to type in a password). This would just require changing the power manager preferences UI to accurately report the figure it's setting into the gnome preferences. Ewen ** Affects: gnome-power-manager (Ubuntu) Importance: Undecided Status: New -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
Attached screenshot showing: - Screen Saver preference time of 8 minutes (480 seconds) - Power Manager display off time of 14 minutes (840 seconds) - gnome configuration apps->gnome-power-manager->timeout->sleep_display_ac value of 6 minutes (360 seconds; 14 minutes - 8 minutes = 6 minutes) - X DPMS information showing an off time of 360 seconds (6 minutes) Computer is on AC power at present. The values are live adjustable, and updating the slider in the power manager UI will result in new values being saved/set with the offset described above. Ewen ** Attachment added: "Example of DPMS off time being difference between power-manager off time and screensaver time" http://launchpadlibrarian.net/11849522/gnome-power-manager-dpms-time-incorrect.pngScreenshot.png -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
** Description changed: Binary package hint: gnome-power-manager In Ubuntu Gutsy (7.10) with gnome-power-manager (2.20.0-0ubuntu6), the System->Preferences->Power Management slider for "Put display to sleep when inactive for" shows values that start with the value set in System->Preferences->Screensaver slider for "Regard the computer as idle after", and go upwards from there. Eg, if the Screensaver figure is set to 8 minutes, the minimum that the Power Manager display sleep can be set to is 8 minutes. However the value that is stored in the gnome configuration does not have this offset (eg, with the screensaver figure of 8 minutes, a power management display off figure of "13 minutes", the value stored in the gnome configuration will be 300 seconds (ie, 5 minutes). With a power management display off figure of "14 minutes" the value stored will be 360 seconds (ie, 6 minutes). The value from the gnome configuration is then applied as an X DPMS "power off" time, eg 300 seconds as the display time off. The result is that the monitor will then turn off after 5 minutes (300 seconds), even though the gnome power management display off time is reported through the user interface as "13 minutes". And thus the monitor turns off even before the screen saver kicks in, and much earlier than it was set to do so. The only combination that actually works sanely is to set both timeouts to the same value (0 minutes difference), which results in a - DPMS off time of 0 seconds, which happens to display the automatic X + DPMS off time of 0 seconds, which happens to disable the automatic X server DPMS off time (leaving gnome power manager to do its own thing). This effect (idle time shown = screen saver time + power manager time; from https://bugs.launchpad.net/ubuntu/+source/gnome-power- manager/+bug/135813/comments/5) would appear to explain this bug: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/59589 too (ie, why the value cannot be set below 11 minutes -- they presumably have a screensaver time of 11 minutes). Obviously I expect that the time specified in gnome power manager to power off the display will be the time in reality, not some arbitrarily shorter time. (I first noticed this with a screen saver time of 8 minutes, and a display off time of 9 minutes -- which caused the screen to power down after 1 minute of inactivity.) There are various ways this could be fixed to work sanely: - have gnome-power-manager not set the X server DPMS time and manage everything itself, counting from when the screen saver kicks in - have gnome-power-manager set the X server DPMS time to the value stored plus the screen saver timeout (so the overall time is consistent with what is shown in the preferences dialog) - have the preferences dialog store the value shown into the gnome preferences (including the amount that is attributed to the screensaver timeout, eg the full 13 minutes == 780 seconds) so that the value can be set directly into the X server DPMS and will give the correct timeout - decouple the power manager and screen saver timeouts again, so that the power manager screen off time can be set from 1 minute upwards. This would also allow having the screen powered down before the screen is locked, which can be useful if one is doing something else nearby but wants to save power (eg, a power manager off time of 3 minutes, and a lock time of 5 minutes, would power the display down pretty rapidly but allow waking it with a keypress without having to type in a password). This would just require changing the power manager preferences UI to accurately report the figure it's setting into the gnome preferences. Ewen -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
I can confirm that on a HP NC6220 after resume with the -generic Ubuntu Gutsy kernel (2.6.22-14.47) the internal speakers are mute (but playback to external speakers and/or headphones is fine). After reverting the patch mentioned earlier in this bug, at comment: https://bugs.launchpad.net/ubuntu/+source/linux- source-2.6.22/+bug/15/comments/1 the internal speakers work after suspend to RAM and resume (in fact the sound continues playing even before the screen is reset). Looking at the line that is re-enabled by reverting that patch, it appears that on the HP NC6220 the internal amplifier does not get powered on again unless the sound card is powered off at suspend time (without that it appears that whatever turns the power to the amplifier back on again doesn't get run when the sound card is powered up again in the resume code). Given the comment in the patch mentioned above I guess in some other laptops the power on code doesn't work at all, so if it's powered down it never gets powered up. So the best fix is probably to put that particular power down line under the control of a kernel module option, so on the HP NC6220, etc, the card can be properly powered down at suspend so it powers up fully at resume, but on other laptops where that causes problems the power down can be skipped. FTR (in case it helps someone else) it appears to be sufficient (after installing the packages needed to compile a kernel) to do: apt-get source linux-image-2.6.22-14-generic cd linux-source-2.6.22-2.6.22 cp /boot/config-`uname -r` .config make oldconfig make sound/pci/snd-intel8x0.ko make sound/pci/snd-intel8x0m.ko # Make a backup of the existing sound modules if desired then... cp -p sound/pci/snd*ko /lib/modules/`uname -r`/kernel/sound/pci/ and then reboot to use the new modules. Ewen -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
Ah, yes, I'd forgotten I'd done that: mkdir .tmp_versions (somewhere after cd'ing into the directory with the source and before running "make...".) After you run the mkdir you can just run "make " again, and it'll continue from where it left off. Apologies for the confusion. Ewen -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
This might seem really obvious, but you did make (the opposite of) change listed in this comment: https://bugs.launchpad.net/ubuntu/+source/linux- source-2.6.22/+bug/15/comments/1 before you built the modules, right? Ie, you have to uncomment the line: pci_set_power_state(pci, pci_choose_state(pci, state)); In the ..._suspend() function. (The change in that patch commented out the line, which is a call to control the power to the sound card -- the HP NC6220 appears to need that call for audio to work on resume.) If you just rebuild without making that change, you'll get exactly what shipped with Ubuntu Gutsy, which as we know doesn't work. If you didn't make that change, try making that change, rebuilding (run the "make ..." lines again and make sure it compiles sound/pci/intel8x0.c and the *.ko files again, then copy them back over and restart. (My list of things to do wasn't intended to be an exhaustive list of all the steps required, just to indicate that it wasn't necessary to fully rebuild the kernel -- which takes a long time -- only the modules.) Ewen -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
"patch -r" (r == reverse) will unapply a patch. In this case given there's only one line changed it's actually easier just to edit the file in a text editor and uncomment the line that was commented out. If you're new to linux you may find the rest of the steps challenging too, and might be better waiting for the next Ubuntu release (Hardy Heron) which should have the fix included. It's due to be released within about 6 weeks I believe. Ewen -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
Tested with Hardy Alpha 4 (x86 Desktop). The Gnome configuration (apps ->gnome-power-manager->timeout) still stores the difference between the screen saver time and the power management time, as in Gutsy. However I wasn't able to trigger the behaviour of the X11 DPMS off timeout being set to a non-zero amount even in half a dozen suspend-to-ram/resume cycles. So either the bug does not exist in Hardy, or it's much harder to trigger, or perhaps its difficult to trigger resuming from a Live CD boot. (It did seem that the resume in Hardy is noticeably faster, even off a Live CD, than in Gutsy, which I guess might change the circumstances of any race condition.) At this stage I think it's probably safe to assume that the issue is resolved in Hardy. (And I planned to upgrade to Hardy anyway, once it's released.) Ewen -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
"patch -r" (r == reverse) will unapply a patch. In this case given there's only one line changed it's actually easier just to edit the file in a text editor and uncomment the line that was commented out. If you're new to linux you may find the rest of the steps challenging too, and might be better waiting for the next Ubuntu release (Hardy Heron) which should have the fix included. It's due to be released within about 6 weeks I believe. Ewen -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
I can confirm that on a HP NC6220 after resume with the -generic Ubuntu Gutsy kernel (2.6.22-14.47) the internal speakers are mute (but playback to external speakers and/or headphones is fine). After reverting the patch mentioned earlier in this bug, at comment: https://bugs.launchpad.net/ubuntu/+source/linux- source-2.6.22/+bug/15/comments/1 the internal speakers work after suspend to RAM and resume (in fact the sound continues playing even before the screen is reset). Looking at the line that is re-enabled by reverting that patch, it appears that on the HP NC6220 the internal amplifier does not get powered on again unless the sound card is powered off at suspend time (without that it appears that whatever turns the power to the amplifier back on again doesn't get run when the sound card is powered up again in the resume code). Given the comment in the patch mentioned above I guess in some other laptops the power on code doesn't work at all, so if it's powered down it never gets powered up. So the best fix is probably to put that particular power down line under the control of a kernel module option, so on the HP NC6220, etc, the card can be properly powered down at suspend so it powers up fully at resume, but on other laptops where that causes problems the power down can be skipped. FTR (in case it helps someone else) it appears to be sufficient (after installing the packages needed to compile a kernel) to do: apt-get source linux-image-2.6.22-14-generic cd linux-source-2.6.22-2.6.22 cp /boot/config-`uname -r` .config make oldconfig make sound/pci/snd-intel8x0.ko make sound/pci/snd-intel8x0m.ko # Make a backup of the existing sound modules if desired then... cp -p sound/pci/snd*ko /lib/modules/`uname -r`/kernel/sound/pci/ and then reboot to use the new modules. Ewen -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
Ah, yes, I'd forgotten I'd done that: mkdir .tmp_versions (somewhere after cd'ing into the directory with the source and before running "make...".) After you run the mkdir you can just run "make " again, and it'll continue from where it left off. Apologies for the confusion. Ewen -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
This might seem really obvious, but you did make (the opposite of) change listed in this comment: https://bugs.launchpad.net/ubuntu/+source/linux- source-2.6.22/+bug/15/comments/1 before you built the modules, right? Ie, you have to uncomment the line: pci_set_power_state(pci, pci_choose_state(pci, state)); In the ..._suspend() function. (The change in that patch commented out the line, which is a call to control the power to the sound card -- the HP NC6220 appears to need that call for audio to work on resume.) If you just rebuild without making that change, you'll get exactly what shipped with Ubuntu Gutsy, which as we know doesn't work. If you didn't make that change, try making that change, rebuilding (run the "make ..." lines again and make sure it compiles sound/pci/intel8x0.c and the *.ko files again, then copy them back over and restart. (My list of things to do wasn't intended to be an exhaustive list of all the steps required, just to indicate that it wasn't necessary to fully rebuild the kernel -- which takes a long time -- only the modules.) Ewen -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin
I've retitled the bug to make it clearer that (a) it's a regression, (b) it only affects Ubuntu Dapper, and (c) it's only the Firefox 1.5.0.9 security update which is affected. At this point I don't think we need any more "it doesn't crash for me, but I'm using some other browser version" reports. It's pretty clearly a flaw introduced with the security update and as far as I can tell affects everyone using Ubuntu Dapper with Firefox 1.5.0.9 and an affected webpage (password only form with saved passwords). Ewens ** Summary changed: - Saved passwords causes crash with Mailman admin (1.5.x) + Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin ** Description changed: Binary package hint: firefox + + [Edit: NOTE: This is a _regression_ in Firefox 1.5.0.9, released as a + security update for Ubuntu Dapper. Functionality that used to work + perfectly now causes the browser to crash hard. The problem appears to + be widely reproduced with the only people unable to reproduce it being + those using some other browser version.] The latest security update for Firefox for Ubuntu Dapper (6.06), version 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, now causes Firefox to crash repeatedly when using a saved password field on a Mailman admin login screen. This did not happen with the previous version (1.5.dfsg+1.5.0.8-0ubuntu0.6.06) or any previous version that I can recall. Other forms with saved passwords may also be affected (I initially thought that it was all saved forms, but it seems the one for launchpad.net isn't affected -- curious). Ubuntu Version: Dapper Drake (6.06) Firefox Version: 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, Reproducable: always How to reproduce: 1. Stop Firefox 2. Remove ~/.mozilla/firefox/PROFILE/signons.txt 3. Start Firefox 4. Go to http://somelistserver/mailman/admindb/mailman 5. Log in 6. Choose to allow Firefox to save the password 7. Observe Firefox crashes 8. Restart Firefox 9. Go back to http://somelistserver/mailman/admindb/mailman 10. Observe Firefox crashes again without displaying the page 11. Go back to step 2 and repeat. 12. Go back to step 2 and repeat choosing NOT to save the password at step 6 and observe Firefox doesn't crash Desired behaviour: As per previous version, should fill in saved password for the form and not crash. Other notes: It doesn't appear necessary for the password to actually be correct; just that it be saved. The crash on visiting the page with a saved password appears to happen aroun the time that the saved password might be pre-filled. Completely removing the saved passwords and starting again doesn't seem to help; as soon as the password is saved the problem reappears. Removing the firefox profile and starting again also doesn't seem to help; again as soon as the password is saved the problem reappears. The only thing I can see which is noticably different between the Mailman login page and, eg, the launchpad.net login page, in terms of saved passwords, is that the Mailman page is password-only, whereas the launchpad.net has an email address as well as the password. Possibly the bug is somehow related to the form being password-only. This behaviour is new with the security update for Ubuntu Dapper which came out this morning. I've used the saved password feature with many previous versions of Firefox without any problems. Knowing the issues which have been reported with Firefox recently, including a password stealing attack, I'd guess that there is a bug in the "fix" chosen to try to defeat that password stealing attack. Finally, for what little it seems to be worth, a backtrace of the coredump: [EMAIL PROTECTED]:/var/tmp$ gdb /usr/lib/firefox/firefox-bin core.10049 GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) Core was generated by `/usr/lib/firefox/firefox-bin -a firefox'. Program terminated with signal 11, Segmentation fault. [] #0 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7e56790 in raise () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x08055e0b in ?? () #3 0x000b in ?? () #4 0xbfaf0e8c in ?? () #5 0x in ?? () (gdb) Ewen -- Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.
[Bug 77859] Patch for Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin
I've now modified the patch from Mozilla Bugzilla (linked earlier in this bug) to apply to Firefox 1.5.0.9 (as shipped with Ubuntu) and recompiled the Firefox package with the patch (which takes about 2 hours, and 1GB of disk space), and appear to have a non-broken version of Firefox that is able to handled saved passwords on forms with and without usernames (ie, properly fill them in, both Mailman's admin screen and Launchpad's login form seemed to work). The modified patch is attached. Perhaps someone at Ubuntu could verify that this patch makes sense, and if so apply it and rebuild the Firefox security update. (I'd offer to make my binary available for others to test, but as far as I can tell Firefox trademark restrictions prevent anyone distributing a non- authorised build, even if it's supposed to be more stable than the one it replaces.) Ewen ** Attachment added: "Firefox 1.5.0.9 password only forms fix" http://librarian.launchpad.net/5859913/firefox-1.5.0.9-saved-passwords-password-only.diff -- Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin
I can confirm that the Firefox package 1.5.dfsg+1.5.0.9-0ubuntu0.6.06.1 no longer crashes when presented with the Mailman admin form where there is a saved password. Thanks for pushing out updated packages. Ewen -- Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
** Description changed: Binary package hint: gnome-power-manager In Ubuntu Gutsy (7.10) with gnome-power-manager (2.20.0-0ubuntu6), the System->Preferences->Power Management slider for "Put display to sleep when inactive for" shows values that start with the value set in System->Preferences->Screensaver slider for "Regard the computer as idle after", and go upwards from there. Eg, if the Screensaver figure is set to 8 minutes, the minimum that the Power Manager display sleep can be - set to is 8 minutes. + set to is 9 minutes (8+1 minutes). However the value that is stored in the gnome configuration does not have this offset (eg, with the screensaver figure of 8 minutes, a power management display off figure of "13 minutes", the value stored in the gnome configuration will be 300 seconds (ie, 5 minutes). With a power management display off figure of "14 minutes" the value stored will be 360 seconds (ie, 6 minutes). The value from the gnome configuration is then applied as an X DPMS "power off" time, eg 300 seconds as the display time off. The result is that the monitor will then turn off after 5 minutes (300 seconds), even though the gnome power management display off time is reported through the user interface as "13 minutes". And thus the monitor turns off even before the screen saver kicks in, and much earlier than it was set to do so. The only combination that actually works sanely is to set both timeouts to the same value (0 minutes difference), which results in a DPMS off time of 0 seconds, which happens to disable the automatic X server DPMS off time (leaving gnome power manager to do its own thing). This effect (idle time shown = screen saver time + power manager time; from https://bugs.launchpad.net/ubuntu/+source/gnome-power- manager/+bug/135813/comments/5) would appear to explain this bug: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/59589 too (ie, why the value cannot be set below 11 minutes -- they presumably have a screensaver time of 11 minutes). Obviously I expect that the time specified in gnome power manager to power off the display will be the time in reality, not some arbitrarily shorter time. (I first noticed this with a screen saver time of 8 minutes, and a display off time of 9 minutes -- which caused the screen to power down after 1 minute of inactivity.) There are various ways this could be fixed to work sanely: - have gnome-power-manager not set the X server DPMS time and manage everything itself, counting from when the screen saver kicks in - have gnome-power-manager set the X server DPMS time to the value stored plus the screen saver timeout (so the overall time is consistent with what is shown in the preferences dialog) - have the preferences dialog store the value shown into the gnome preferences (including the amount that is attributed to the screensaver timeout, eg the full 13 minutes == 780 seconds) so that the value can be set directly into the X server DPMS and will give the correct timeout - decouple the power manager and screen saver timeouts again, so that the power manager screen off time can be set from 1 minute upwards. This would also allow having the screen powered down before the screen is locked, which can be useful if one is doing something else nearby but wants to save power (eg, a power manager off time of 3 minutes, and a lock time of 5 minutes, would power the display down pretty rapidly but allow waking it with a keypress without having to type in a password). This would just require changing the power manager preferences UI to accurately report the figure it's setting into the gnome preferences. Ewen ** Description changed: Binary package hint: gnome-power-manager In Ubuntu Gutsy (7.10) with gnome-power-manager (2.20.0-0ubuntu6), the System->Preferences->Power Management slider for "Put display to sleep when inactive for" shows values that start with the value set in System->Preferences->Screensaver slider for "Regard the computer as idle after", and go upwards from there. Eg, if the Screensaver figure is set to 8 minutes, the minimum that the Power Manager display sleep can be set to is 9 minutes (8+1 minutes). However the value that is stored in the gnome configuration does not have this offset (eg, with the screensaver figure of 8 minutes, a power management display off figure of "13 minutes", the value stored in the gnome configuration will be 300 seconds (ie, 5 minutes). With a power management display off figure of "14 minutes" the value stored will be 360 seconds (ie, 6 minutes). The value from the gnome configuration is then applied as an X DPMS "power off" time, eg 300 seconds as the display time off. The result is that the monitor will then turn off after 5 minutes (300 seconds), even though the gnome power management display off time
[Bug 59589] Re: display sleep time - why 11 minutes
I suspect the "11 minutes" minimum is coming from your system->preferences->screensaver being set to 11 minutes; the figure reported in the gnome power manager dialog seems to be offset by the screensaver amount (even though it doesn't seem to be implemented like that); I've reported a separate bug about this disparity between the UI and what actually happens: https://bugs.launchpad.net/ubuntu/+source/gnome-power- manager/+bug/190537 For now the best work around I can find is to set the gnome power manager display off timeout to be sufficiently large that the difference between that timeout and the screensaver timeout is the power off time that I actually want. Ewen -- display sleep time - why 11 minutes https://bugs.launchpad.net/bugs/59589 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] [NEW] [Gutsy] Display sleep sets wrong DPMS off time
Public bug reported: Binary package hint: gnome-power-manager In Ubuntu Gutsy (7.10) with gnome-power-manager (2.20.0-0ubuntu6), the System->Preferences->Power Management slider for "Put display to sleep when inactive for" shows values that start with the value set in System->Preferences->Screensaver slider for "Regard the computer as idle after", and go upwards from there. Eg, if the Screensaver figure is set to 8 minutes, the minimum that the Power Manager display sleep can be set to is 8 minutes. However the value that is stored in the gnome configuration does not have this offset (eg, with the screensaver figure of 8 minutes, a power management display off figure of "13 minutes", the value stored in the gnome configuration will be 300 seconds (ie, 5 minutes). With a power management display off figure of "14 minutes" the value stored will be 360 seconds (ie, 6 minutes). The value from the gnome configuration is then applied as an X DPMS "power off" time, eg 300 seconds as the display time off. The result is that the monitor will then turn off after 5 minutes (300 seconds), even though the gnome power management display off time is reported through the user interface as "13 minutes". And thus the monitor turns off even before the screen saver kicks in, and much earlier than it was set to do so. The only combination that actually works sanely is to set both timeouts to the same value (0 minutes difference), which results in a DPMS off time of 0 seconds, which happens to display the automatic X server DPMS off time (leaving gnome power manager to do its own thing). This effect (idle time shown = screen saver time + power manager time; from https://bugs.launchpad.net/ubuntu/+source/gnome-power- manager/+bug/135813/comments/5) would appear to explain this bug: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/59589 too (ie, why the value cannot be set below 11 minutes -- they presumably have a screensaver time of 11 minutes). Obviously I expect that the time specified in gnome power manager to power off the display will be the time in reality, not some arbitrarily shorter time. (I first noticed this with a screen saver time of 8 minutes, and a display off time of 9 minutes -- which caused the screen to power down after 1 minute of inactivity.) There are various ways this could be fixed to work sanely: - have gnome-power-manager not set the X server DPMS time and manage everything itself, counting from when the screen saver kicks in - have gnome-power-manager set the X server DPMS time to the value stored plus the screen saver timeout (so the overall time is consistent with what is shown in the preferences dialog) - have the preferences dialog store the value shown into the gnome preferences (including the amount that is attributed to the screensaver timeout, eg the full 13 minutes == 780 seconds) so that the value can be set directly into the X server DPMS and will give the correct timeout - decouple the power manager and screen saver timeouts again, so that the power manager screen off time can be set from 1 minute upwards. This would also allow having the screen powered down before the screen is locked, which can be useful if one is doing something else nearby but wants to save power (eg, a power manager off time of 3 minutes, and a lock time of 5 minutes, would power the display down pretty rapidly but allow waking it with a keypress without having to type in a password). This would just require changing the power manager preferences UI to accurately report the figure it's setting into the gnome preferences. Ewen ** Affects: gnome-power-manager (Ubuntu) Importance: Undecided Status: New -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
Attached screenshot showing: - Screen Saver preference time of 8 minutes (480 seconds) - Power Manager display off time of 14 minutes (840 seconds) - gnome configuration apps->gnome-power-manager->timeout->sleep_display_ac value of 6 minutes (360 seconds; 14 minutes - 8 minutes = 6 minutes) - X DPMS information showing an off time of 360 seconds (6 minutes) Computer is on AC power at present. The values are live adjustable, and updating the slider in the power manager UI will result in new values being saved/set with the offset described above. Ewen ** Attachment added: "Example of DPMS off time being difference between power-manager off time and screensaver time" http://launchpadlibrarian.net/11849522/gnome-power-manager-dpms-time-incorrect.pngScreenshot.png -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
** Description changed: Binary package hint: gnome-power-manager In Ubuntu Gutsy (7.10) with gnome-power-manager (2.20.0-0ubuntu6), the System->Preferences->Power Management slider for "Put display to sleep when inactive for" shows values that start with the value set in System->Preferences->Screensaver slider for "Regard the computer as idle after", and go upwards from there. Eg, if the Screensaver figure is set to 8 minutes, the minimum that the Power Manager display sleep can be set to is 8 minutes. However the value that is stored in the gnome configuration does not have this offset (eg, with the screensaver figure of 8 minutes, a power management display off figure of "13 minutes", the value stored in the gnome configuration will be 300 seconds (ie, 5 minutes). With a power management display off figure of "14 minutes" the value stored will be 360 seconds (ie, 6 minutes). The value from the gnome configuration is then applied as an X DPMS "power off" time, eg 300 seconds as the display time off. The result is that the monitor will then turn off after 5 minutes (300 seconds), even though the gnome power management display off time is reported through the user interface as "13 minutes". And thus the monitor turns off even before the screen saver kicks in, and much earlier than it was set to do so. The only combination that actually works sanely is to set both timeouts to the same value (0 minutes difference), which results in a - DPMS off time of 0 seconds, which happens to display the automatic X + DPMS off time of 0 seconds, which happens to disable the automatic X server DPMS off time (leaving gnome power manager to do its own thing). This effect (idle time shown = screen saver time + power manager time; from https://bugs.launchpad.net/ubuntu/+source/gnome-power- manager/+bug/135813/comments/5) would appear to explain this bug: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/59589 too (ie, why the value cannot be set below 11 minutes -- they presumably have a screensaver time of 11 minutes). Obviously I expect that the time specified in gnome power manager to power off the display will be the time in reality, not some arbitrarily shorter time. (I first noticed this with a screen saver time of 8 minutes, and a display off time of 9 minutes -- which caused the screen to power down after 1 minute of inactivity.) There are various ways this could be fixed to work sanely: - have gnome-power-manager not set the X server DPMS time and manage everything itself, counting from when the screen saver kicks in - have gnome-power-manager set the X server DPMS time to the value stored plus the screen saver timeout (so the overall time is consistent with what is shown in the preferences dialog) - have the preferences dialog store the value shown into the gnome preferences (including the amount that is attributed to the screensaver timeout, eg the full 13 minutes == 780 seconds) so that the value can be set directly into the X server DPMS and will give the correct timeout - decouple the power manager and screen saver timeouts again, so that the power manager screen off time can be set from 1 minute upwards. This would also allow having the screen powered down before the screen is locked, which can be useful if one is doing something else nearby but wants to save power (eg, a power manager off time of 3 minutes, and a lock time of 5 minutes, would power the display down pretty rapidly but allow waking it with a keypress without having to type in a password). This would just require changing the power manager preferences UI to accurately report the figure it's setting into the gnome preferences. Ewen -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
I've just attempted to reproduce it now, with the same results as you (ie, the DPMS off time isn't being set as it was previously). I wondered whether it had something to do with either s2ram, or adding a monitor on resume (eg, docking with an external monitor) but neither of those seem to be triggering it now. I'll keep an eye out for it happening again in the next couple of weeks (it's pretty obvious as the monitor starts turning off pretty soon after I stop typing), and if it does happen try to figure out a more precise sequence to get it into that situation. If I don't see it again, perhaps it got resolved by a recent update. Thanks for trying to reproduce it. Ewen -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
I think I've figured out how to trigger it. The computer in question is a laptop, with an external CRT connected via a docking station some of the time -- and all the times the DPMS Off: value has been incorrectly set, the laptop has been docked with the CRT connected. In order to trigger it I seem to need to: - boot up docked, with the CRT on - suspend to RAM - turn off the CRT - unsuspend (which is hit the power button in the case of this laptop) - while unsuspending, turn on the CRT (at the "right" time) In that situation I get: DPMS (Energy Star): Standby: 0Suspend: 0Off: 60 DPMS is Enabled Monitor is On or: DPMS (Energy Star): Standby: 0Suspend: 0Off: 300 DPMS is Enabled Monitor is On with the "Off:" time being set to the difference between the Power Mangement time and the Screensaver time. And if that time is non-zero, then playing with the adjusters seems to set the Off: time to the difference between the two (which definitely seems to be the wrong behaviour to me). So there appears to be two things going on: - there's something in Gnome (presumably Power Management) which is incorrectly setting the DPMS Off time to the difference between the Power Management off time and the Screensaver time (possibly when it notices a non-zero Off: time -- but irrespective, it's still doing the wrong thing: if it's going to set it, it should be to the total Power Management off time, or 0) - there's a race condition between the CRT waking up and the DPMS being reset to zero (possibly by some other power management program or task), where the DPMS setting doesn't "stick" until the CRT is ready to accept it (for which the fix is presumably to have the power management reapply the setting a little while, eg, 30 seconds, after either (a) unsuspend, or (b) the arrival of a new monitor. It appears once it becomes a non-zero value it's difficult to get the "reset to 0" behaviour back; I did manage it with one suspend (powering on the CRT a little earlier in the unsuspend), but other attempts still didn't reset it to zero (including ensuring the CRT was fully powered on before unsuspending). In case it matters, the laptop is a HP NC6220, which has Intel integrated graphics (Intel 915GM), with a HP docking station, and a Viewsonic E70 CRT connected to it. Anyway it seems to me that if the Gnome power manager is going to manage the display power off itself, it should probably be explicitly resetting the X DPMS Off: time (and others) to 0, and definitely never setting it to the difference between the screensaver time and the Power Management screen off time. That seems to be the core bug. Ewen -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
Resetting status to New since there is now (hopefully) a way for others to reproduce it. ** Changed in: gnome-power-manager (Ubuntu) Status: Invalid => New -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
Tested with Hardy Alpha 4 (x86 Desktop). The Gnome configuration (apps ->gnome-power-manager->timeout) still stores the difference between the screen saver time and the power management time, as in Gutsy. However I wasn't able to trigger the behaviour of the X11 DPMS off timeout being set to a non-zero amount even in half a dozen suspend-to-ram/resume cycles. So either the bug does not exist in Hardy, or it's much harder to trigger, or perhaps its difficult to trigger resuming from a Live CD boot. (It did seem that the resume in Hardy is noticeably faster, even off a Live CD, than in Gutsy, which I guess might change the circumstances of any race condition.) At this stage I think it's probably safe to assume that the issue is resolved in Hardy. (And I planned to upgrade to Hardy anyway, once it's released.) Ewen -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
lspci -vvnn on HP NC6220 laptop attached, as requested. ** Attachment added: "lspci -vvnn on HP NC6220" http://launchpadlibrarian.net/11928656/hp-nc6220-lspci-vvnn.txt -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Firefox: saved passwords causes crash with Mailman admin page
Public bug reported: Binary package hint: firefox The latest security update for Firefox for Ubuntu Dapper (6.06), version 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, now causes Firefox to crash repeatedly when using a saved password field on a Mailman admin login screen. This did not happen with the previous version (1.5.dfsg+1.5.0.8-0ubuntu0.6.06) or any previous version that I can recall. Other forms with saved passwords may also be affected (I initially thought that it was all saved forms, but it seems the one for launchpad.net isn't affected -- curious). Ubuntu Version: Dapper Drake (6.06) Firefox Version: 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, Reproducable: always How to reproduce: 1. Stop Firefox 2. Remove ~/.mozilla/firefox/PROFILE/signons.txt 3. Start Firefox 4. Go to http://somelistserver/mailman/admindb/mailman 5. Log in 6. Choose to allow Firefox to save the password 7. Observe Firefox crashes 8. Restart Firefox 9. Go back to http://somelistserver/mailman/admindb/mailman 10. Observe Firefox crashes again without displaying the page 11. Go back to step 2 and repeat. 12. Go back to step 2 and repeat choosing NOT to save the password at step 6 and observe Firefox doesn't crash Desired behaviour: As per previous version, should fill in saved password for the form and not crash. Other notes: It doesn't appear necessary for the password to actually be correct; just that it be saved. The crash on visiting the page with a saved password appears to happen aroun the time that the saved password might be pre-filled. Completely removing the saved passwords and starting again doesn't seem to help; as soon as the password is saved the problem reappears. Removing the firefox profile and starting again also doesn't seem to help; again as soon as the password is saved the problem reappears. The only thing I can see which is noticably different between the Mailman login page and, eg, the launchpad.net login page, in terms of saved passwords, is that the Mailman page is password-only, whereas the launchpad.net has an email address as well as the password. Possibly the bug is somehow related to the form being password-only. This behaviour is new with the security update for Ubuntu Dapper which came out this morning. I've used the saved password feature with many previous versions of Firefox without any problems. Knowing the issues which have been reported with Firefox recently, including a password stealing attack, I'd guess that there is a bug in the "fix" chosen to try to defeat that password stealing attack. Finally, for what little it seems to be worth, a backtrace of the coredump: [EMAIL PROTECTED]:/var/tmp$ gdb /usr/lib/firefox/firefox-bin core.10049 GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) Core was generated by `/usr/lib/firefox/firefox-bin -a firefox'. Program terminated with signal 11, Segmentation fault. [] #0 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7e56790 in raise () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x08055e0b in ?? () #3 0x000b in ?? () #4 0xbfaf0e8c in ?? () #5 0x in ?? () (gdb) Ewen ** Affects: firefox (Ubuntu) Importance: Undecided Status: Unconfirmed -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
Issolated test case: http://www.naos.co.nz/tmp/ubuntu/firefox/mailman-signon-page.html Steps to reproduce is slightly different here, I think because there's no real form processing behind it. To reproduce: 1. Go to URL 2Enter some string to be the password, eg "test" (it doens't matter, just needs something) 3. Choose to remember the password 4. Observe "success" message 5. Go back to URL (eg, click on the link in the success page) 6. Observe browser crashes 7. Restart firefox 8. Go to URL 9. Observe browser crashes 10. Remove ~/.mozilla/firefox/PROFILE/signons.txt 11. Start firefox 12. Go to URL 13. Observe browser doesn't crash 14. Repeat from 2 Test case (stripped down version of the Mailman admin page) is attached. The "success" page is just a stub HTML page with a link to this bug and back to the test case for convenience. Something like the launchpad.net signon form can serve as an example that doesn't crash. Ewen ** Attachment added: "Issolated test case (extracted from Mailman admin signon form)" http://librarian.launchpad.net/5593238/mailman-signon-page.html -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
As suggested by Peter Cherriman (https://launchpad.net/~pjcherriman) in comment: https://launchpad.net/ubuntu/+source/firefox/+bug/77859/comments/3 I've installed the firefox-dbg package (ie, debug symbols), and regenerated the core dump and run gdb over it. Like him I see: nsPasswordManager::AttachToInput (this=0x89f6368, aElement=0x0) at nsPasswordManager.cpp:1962 as the topmost item on the stack prior to the signal handler being invoked, so I too suspect that aElement=0x0 is somehow involved in the segmentation fault. Full gdb backtrace follows. Ewen -=- cut here -=- [EMAIL PROTECTED]:/var/tmp$ ulimit -c unlimited [EMAIL PROTECTED]:/var/tmp$ firefox & [1] 26943 [EMAIL PROTECTED]:/var/tmp$ [1]+ Segmentation fault (core dumped) firefox [EMAIL PROTECTED]:/var/tmp$ ls -l core* -rw--- 1 ewen ewen 55312384 2007-01-06 12:38 core.26943 [EMAIL PROTECTED]:/var/tmp$ gdb /usr/lib/firefox/firefox-bin core.26943 GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/ lib/tls/i686/cmov/libthread_db.so.1". Core was generated by `/usr/lib/firefox/firefox-bin -a firefox'. Program terminated with signal 11, Segmentation fault. warning: Can't read pathname for load map: Input/output error. Reading symbols from /usr/lib/firefox/libmozjs.so...Reading symbols from /usr/li b/debug/usr/lib/firefox/libmozjs.so...done. done. [] Loaded symbols for /usr/lib/firefox/components/libnkgnomevfs.so #0 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7d8d790 in raise () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x08055e0b in nsProfileLock::FatalSignalHandler (signo=-1210510412) at nsProfileLock.cpp:206 #3 #4 0xb67e65cc in nsPasswordManager::AttachToInput (this=0x89f6368, aElement=0x0) at nsPasswordManager.cpp:1962 #5 0xb67e7724 in nsPasswordManager::OnStateChange (this=0x89f6368, aWebProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsPasswordManager.cpp:948 #6 0xb5dd3e62 in nsDocLoader::FireOnStateChange (this=0x8205c88, aProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsDocLoader.cpp:1210 #7 0xb5dd3ea0 in nsDocLoader::FireOnStateChange (this=0x835a5b8, aProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsDocLoader.cpp:1217 #8 0xb5dd3ea0 in nsDocLoader::FireOnStateChange (this=0x86a6cd8, aProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsDocLoader.cpp:1217 #9 0xb5dd423b in nsDocLoader::doStopDocumentLoad (this=0x86a6cd8, request=0x86939b4, aStatus=0) at nsDocLoader.cpp:833 #10 0xb5dd4313 in nsDocLoader::DocLoaderIsEmpty (this=0x86a6cd8) at nsDocLoader.cpp:739 #11 0xb5dd45df in nsDocLoader::OnStopRequest (this=0x86a6cd8, aRequest=0x890d118, aCtxt=0x0, aStatus=0) at nsDocLoader.cpp:662 #12 0xb723ae35 in nsLoadGroup::RemoveRequest (this=0x86a6740, request=0x890d118, ctxt=0x0, aStatus=0) at nsLoadGroup.cpp:732 #13 0xb56c0c6e in nsDocument::UnblockOnload (this=0x88ff600) at nsDocument.cpp:5015 #14 0xb56e256a in DestroyImagePLEvent (aEvent=0x8a09438) at nsImageLoadingContent.cpp:668 #15 0xb7e40351 in PL_DestroyEvent (self=0x8a09438) at plevent.c:727 #16 0xb7e403bd in PL_HandleEvent (self=0x8a09438) at plevent.c:699 #17 0xb7e40b2e in PL_ProcessPendingEvents (self=0x80d3758) at plevent.c:623 #18 0xb7e41ed0 in nsEventQueueImpl::ProcessPendingEvents (this=0x80d3710) at nsEventQueue.cpp:417 #19 0xb68a3449 in event_processor_callback (source=0x8312d28, condition=G_IO_IN, data=0x0) at nsAppShell.cpp:67 #20 0xb77bc52c in g_vasprintf () from /usr/lib/libglib-2.0.so.0 #21 0xb77958d6 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #22 0xb7798996 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #23 0xb7798cb8 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #24 0xb7bc7765 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #25 0xb68a38da in nsAppShell::Run (this=0x814e778) at nsAppShell.cpp:139 #26 0xb67c33d2 in nsAppStartup::Run (this=0x814e738) at nsAppStartup.cpp:150 #27 0x0804f321 in XRE_main (argc=3, argv=0xbf82acf4, aAppData=0x80595e0) at nsAppRunner.cpp:2380 #28 0x0804abe4 in main (argc=0, argv=0x0) at nsBrowserApp.cpp:61 #29 0xb752bea2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 #30 0x0804ab31 in _start () at ../sysdeps/i386/elf/start.S:119 (gdb) -=- cut here -=- -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
Source for affected function that is segfaulting: void nsPasswordManager::AttachToInput(nsIDOMHTMLInputElement* aElement) { nsCOMPtr targ = do_QueryInterface(aElement); nsIDOMEventListener* listener = NS_STATIC_CAST(nsIDOMFocusListener*, this); targ->AddEventListener(NS_LITERAL_STRING("blur"), listener, PR_FALSE); targ->AddEventListener(NS_LITERAL_STRING("DOMAutoComplete"), listener, PR_FALSE); mAutoCompleteInputs.Put(aElement, 1); } (1956-1966 in firefox-1.5.dfsg+1.5.0.9/toolkit/components/passwordmgr/base/nsPasswordManager.cpp) The affected line, 1962, is: targ->AddEventListener(NS_LITERAL_STRING("blur"), listener, PR_FALSE); and appears to be segfaulting because the raw pointer inside targ is 0x0: (gdb) print targ $1 = { = {mRawPtr = 0x0}, } I _think_ that the raw pointer inside targ is null because atElement is null, but there's too much magic in the ns smart pointers to trace through without ever having seen the code before. Working back up the stack, the caller is: -=- cut here -=- (gdb) up #5 0xb67e7724 in nsPasswordManager::OnStateChange (this=0x89f6368, aWebProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsPasswordManager.cpp:948 948 AttachToInput(userField); (gdb) print userField $6 = { = {mRawPtr = 0x0}, } (gdb) -=- cut here -=- where the function contains the inline comment: -=- cut here -=- // We can auto-prefill the username and password if there is only // one stored login that matches the username and password field names // on the form in question. Note that we only need to worry about a // single login per form. -=- cut here -=- All of which tends to confirm my impression that the problem is prefilling in a save password on forms which have only a password field and no username field, Whatever changed in the code appears to no longer properly handle the situation where there is no username field and instead seems to assume that there'll be a username field to attach to if it finds a password field When it tries to attach to a non-existantant username field, thus dereferencing the null, it crashes. Ewen -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
I managed to find the source to firefox-1.5.dfsg+1.5.0.8 on a mirror (http://mirror.xmu.edu.cn/archive.ubuntu.com/ubuntu/pool/main/f/firefox/; it's already expired out of security.ubuntu.com and archive.ubuntu.com). Diff between firefox-1.5.dfsg+1.5.0.8 and firefox-1.5.dfsg+1.5.0.9 reveals that a guard on userField being non-null was removed between those two versions, viz: -=- cut here -=- @@ -941,20 +945,20 @@ } if (firstMatch && !attachedToInput) { - nsAutoString buffer; - - if (userField) { + AttachToInput(userField); + + if (prefillForm) { +nsAutoString buffer; if (NS_FAILED(DecryptData(firstMatch->userValue, buffer))) goto done; -=- cut here -=- (Full diff of that file below.) So since it appears to be fatal to call AttachToInput(NULL), it appears that the function has been "deliberately" changed to cause Firefox to crash when faced with a presaved form which has no username field. This seems to be undesirable. At very worst it should refuse to fill in the form and continue running; ideally it would continue the previous Firefox behaviour and fill in the form without fuss. There's nothing in the comments or changelog to explain why the guard on userField being non-null was removed. The entire changelog for .8 to .9 is: -=- cut here -=- firefox (1.5.dfsg+1.5.0.9-0ubuntu0.6.06) dapper-security; urgency=low * New upstream security update: - CVE-2006-6504, MFSA 2006-73: SVG Processing Remote Code Execution. - CVE-2006-6503, MFSA 2006-72: XSS by setting img.src to javascript: URI. - CVE-2006-6502, MFSA 2006-71: LiveConnect crash finalizing JS objects. - CVE-2006-6501, MFSA 2006-70: Privilege escallation using watch point. - CVE-2006-6497, CVE-2006-6498, CVE-2006-6499, MFSA 2006-68: Crashes with evidence of memory corruption. -- Kees Cook <[EMAIL PROTECTED]> Tue, 2 Jan 2007 11:23:28 -0800 -=- cut here -=- None of the CVE or MFSA documents referenced talk about the password manager or saved password exploits or appear to explain why this code was changed. Given other security discussion I'm aware of I assume it's part of an attempt to avoid the recently publicised password stealing attack through user-created forms being pre-filled. The list appears to come from here: http://www.mozilla.org/projects/security/known- vulnerabilities.html#firefox1.5.0.9 which is referenced from here: http://www.mozilla.com/en-US/firefox/releases/1.5.0.9.html which is the upstream announcement of 1.5.0.9. Most of the change in nsPasswordManager.cpp appears to have come from upstream (comparing diffs with and without the ubuntu dapper patches). However upstream 1.5.0.8 upstream also didn't have the guard on userField being non-NULL. That guard was being added by the ubuntu dapper patch in 1.5.0.8, but is not being added in 1.5.0.9. In particular we seem to have lost this patch: -=- cut here -=- * toolkit/components/passwordmgr/base/nsPasswordManager.cpp: Take patch from bz#235336 as suggested by Ian Jackson to allow password manager to work with sites that only have a password field, no username. -- Eric Dorland <[EMAIL PROTECTED]> Mon, 6 Feb 2006 23:10:29 -0500 -=- cut here -=- I'm not sure what "bz#235336" is or where it can be found, but I strongly suspect that it includes the guard on userField being non-null. So it appears that a combination of an upstream change and dropping a patch that allowed password manager to work with password-only forms has caused this crash. It also appears to me that upstream will have this bug (crash with saved passwords on forms with only a password field) if I'm reading their code correctly. Any chance we can have this "bz#235336" patch reapplied and/or the guard on userField back again, so password manager works with password only forms and firefox doesn't crash? Ewen -=- full 1.5.0.8 to 1.5.0.9 diff for nsPasswordManager.cpp -=- [EMAIL PROTECTED]:/var/tmp/ubuntu-dapper-firefox$ diff -u firefox-1.5.dfsg+1.5.0.{8,9}/toolkit/components/passwordmgr/base/nsPasswordManager.cpp --- firefox-1.5.dfsg+1.5.0.8/toolkit/components/passwordmgr/base/nsPasswordManager.cpp 2007-01-06 13:45:37.0 +1300 +++ firefox-1.5.dfsg+1.5.0.9/toolkit/components/passwordmgr/base/nsPasswordManager.cpp 2007-01-06 12:53:22.0 +1300 @@ -815,6 +815,10 @@ PRUint32 formCount; forms->GetLength(&formCount); + + // check to see if we should formfill. failure is non-fatal + PRBool prefillForm = PR_TRUE; + mPrefBranch->GetBoolPref("prefillForms", &prefillForm); // We can auto-prefill the username and password if there is only // one stored login that matches the username and password field names @@ -907,7 +911,7 @@ continue; } - if (!oldUserValue.IsEmpty()) { + if (!oldUserValue.IsEmpty() && prefillForm) { // The page has prefilled a username. // If it matches any of our saved usernames, prefill the password
[Bug 77859] Firefox: Regression: saved passwords: password only forms crash firefox (patch lost)
Found the patch that got lost: Mozilla Bugzilla 235336: https://bugzilla.mozilla.org/show_bug.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&id=235336 (was obvious once I guessed that "bz" == "Bugzilla" not "Baz"/"Bazzar" or similar.) And the relevant patch: https://bugzilla.mozilla.org/attachment.cgi?id=185577 referred to does indeed add the guard on userField being non-NULL. Please apply, modified as necessary to fit 1.5.0.9. Ewen -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
In the hope that this will bring the bug to the firefox/security maintainers attention, I've changed the status to "confirmed" given (a) the number of bugs which have been marked as a duplicate of this bug, and (b) that several people have reported they can reproduce the bug. It would be nice to have some indication from the Firefox maintainer and/or the Ubuntu security folks as to when this regression introduced with the Dapper 1.5.0.9 package might be looked at. Ewen ** Changed in: firefox (Ubuntu) Status: Unconfirmed => Confirmed -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
I've just attempted to reproduce it now, with the same results as you (ie, the DPMS off time isn't being set as it was previously). I wondered whether it had something to do with either s2ram, or adding a monitor on resume (eg, docking with an external monitor) but neither of those seem to be triggering it now. I'll keep an eye out for it happening again in the next couple of weeks (it's pretty obvious as the monitor starts turning off pretty soon after I stop typing), and if it does happen try to figure out a more precise sequence to get it into that situation. If I don't see it again, perhaps it got resolved by a recent update. Thanks for trying to reproduce it. Ewen -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
I think I've figured out how to trigger it. The computer in question is a laptop, with an external CRT connected via a docking station some of the time -- and all the times the DPMS Off: value has been incorrectly set, the laptop has been docked with the CRT connected. In order to trigger it I seem to need to: - boot up docked, with the CRT on - suspend to RAM - turn off the CRT - unsuspend (which is hit the power button in the case of this laptop) - while unsuspending, turn on the CRT (at the "right" time) In that situation I get: DPMS (Energy Star): Standby: 0Suspend: 0Off: 60 DPMS is Enabled Monitor is On or: DPMS (Energy Star): Standby: 0Suspend: 0Off: 300 DPMS is Enabled Monitor is On with the "Off:" time being set to the difference between the Power Mangement time and the Screensaver time. And if that time is non-zero, then playing with the adjusters seems to set the Off: time to the difference between the two (which definitely seems to be the wrong behaviour to me). So there appears to be two things going on: - there's something in Gnome (presumably Power Management) which is incorrectly setting the DPMS Off time to the difference between the Power Management off time and the Screensaver time (possibly when it notices a non-zero Off: time -- but irrespective, it's still doing the wrong thing: if it's going to set it, it should be to the total Power Management off time, or 0) - there's a race condition between the CRT waking up and the DPMS being reset to zero (possibly by some other power management program or task), where the DPMS setting doesn't "stick" until the CRT is ready to accept it (for which the fix is presumably to have the power management reapply the setting a little while, eg, 30 seconds, after either (a) unsuspend, or (b) the arrival of a new monitor. It appears once it becomes a non-zero value it's difficult to get the "reset to 0" behaviour back; I did manage it with one suspend (powering on the CRT a little earlier in the unsuspend), but other attempts still didn't reset it to zero (including ensuring the CRT was fully powered on before unsuspending). In case it matters, the laptop is a HP NC6220, which has Intel integrated graphics (Intel 915GM), with a HP docking station, and a Viewsonic E70 CRT connected to it. Anyway it seems to me that if the Gnome power manager is going to manage the display power off itself, it should probably be explicitly resetting the X DPMS Off: time (and others) to 0, and definitely never setting it to the difference between the screensaver time and the Power Management screen off time. That seems to be the core bug. Ewen -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
Resetting status to New since there is now (hopefully) a way for others to reproduce it. ** Changed in: gnome-power-manager (Ubuntu) Status: Invalid => New -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
Tested with Hardy Alpha 4 (x86 Desktop). The Gnome configuration (apps ->gnome-power-manager->timeout) still stores the difference between the screen saver time and the power management time, as in Gutsy. However I wasn't able to trigger the behaviour of the X11 DPMS off timeout being set to a non-zero amount even in half a dozen suspend-to-ram/resume cycles. So either the bug does not exist in Hardy, or it's much harder to trigger, or perhaps its difficult to trigger resuming from a Live CD boot. (It did seem that the resume in Hardy is noticeably faster, even off a Live CD, than in Gutsy, which I guess might change the circumstances of any race condition.) At this stage I think it's probably safe to assume that the issue is resolved in Hardy. (And I planned to upgrade to Hardy anyway, once it's released.) Ewen -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
** Description changed: Binary package hint: gnome-power-manager In Ubuntu Gutsy (7.10) with gnome-power-manager (2.20.0-0ubuntu6), the System->Preferences->Power Management slider for "Put display to sleep when inactive for" shows values that start with the value set in System->Preferences->Screensaver slider for "Regard the computer as idle after", and go upwards from there. Eg, if the Screensaver figure is set to 8 minutes, the minimum that the Power Manager display sleep can be - set to is 8 minutes. + set to is 9 minutes (8+1 minutes). However the value that is stored in the gnome configuration does not have this offset (eg, with the screensaver figure of 8 minutes, a power management display off figure of "13 minutes", the value stored in the gnome configuration will be 300 seconds (ie, 5 minutes). With a power management display off figure of "14 minutes" the value stored will be 360 seconds (ie, 6 minutes). The value from the gnome configuration is then applied as an X DPMS "power off" time, eg 300 seconds as the display time off. The result is that the monitor will then turn off after 5 minutes (300 seconds), even though the gnome power management display off time is reported through the user interface as "13 minutes". And thus the monitor turns off even before the screen saver kicks in, and much earlier than it was set to do so. The only combination that actually works sanely is to set both timeouts to the same value (0 minutes difference), which results in a DPMS off time of 0 seconds, which happens to disable the automatic X server DPMS off time (leaving gnome power manager to do its own thing). This effect (idle time shown = screen saver time + power manager time; from https://bugs.launchpad.net/ubuntu/+source/gnome-power- manager/+bug/135813/comments/5) would appear to explain this bug: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/59589 too (ie, why the value cannot be set below 11 minutes -- they presumably have a screensaver time of 11 minutes). Obviously I expect that the time specified in gnome power manager to power off the display will be the time in reality, not some arbitrarily shorter time. (I first noticed this with a screen saver time of 8 minutes, and a display off time of 9 minutes -- which caused the screen to power down after 1 minute of inactivity.) There are various ways this could be fixed to work sanely: - have gnome-power-manager not set the X server DPMS time and manage everything itself, counting from when the screen saver kicks in - have gnome-power-manager set the X server DPMS time to the value stored plus the screen saver timeout (so the overall time is consistent with what is shown in the preferences dialog) - have the preferences dialog store the value shown into the gnome preferences (including the amount that is attributed to the screensaver timeout, eg the full 13 minutes == 780 seconds) so that the value can be set directly into the X server DPMS and will give the correct timeout - decouple the power manager and screen saver timeouts again, so that the power manager screen off time can be set from 1 minute upwards. This would also allow having the screen powered down before the screen is locked, which can be useful if one is doing something else nearby but wants to save power (eg, a power manager off time of 3 minutes, and a lock time of 5 minutes, would power the display down pretty rapidly but allow waking it with a keypress without having to type in a password). This would just require changing the power manager preferences UI to accurately report the figure it's setting into the gnome preferences. Ewen ** Description changed: Binary package hint: gnome-power-manager In Ubuntu Gutsy (7.10) with gnome-power-manager (2.20.0-0ubuntu6), the System->Preferences->Power Management slider for "Put display to sleep when inactive for" shows values that start with the value set in System->Preferences->Screensaver slider for "Regard the computer as idle after", and go upwards from there. Eg, if the Screensaver figure is set to 8 minutes, the minimum that the Power Manager display sleep can be set to is 9 minutes (8+1 minutes). However the value that is stored in the gnome configuration does not have this offset (eg, with the screensaver figure of 8 minutes, a power management display off figure of "13 minutes", the value stored in the gnome configuration will be 300 seconds (ie, 5 minutes). With a power management display off figure of "14 minutes" the value stored will be 360 seconds (ie, 6 minutes). The value from the gnome configuration is then applied as an X DPMS "power off" time, eg 300 seconds as the display time off. The result is that the monitor will then turn off after 5 minutes (300 seconds), even though the gnome power management display off time
[Bug 59589] Re: display sleep time - why 11 minutes
I suspect the "11 minutes" minimum is coming from your system->preferences->screensaver being set to 11 minutes; the figure reported in the gnome power manager dialog seems to be offset by the screensaver amount (even though it doesn't seem to be implemented like that); I've reported a separate bug about this disparity between the UI and what actually happens: https://bugs.launchpad.net/ubuntu/+source/gnome-power- manager/+bug/190537 For now the best work around I can find is to set the gnome power manager display off timeout to be sufficiently large that the difference between that timeout and the screensaver timeout is the power off time that I actually want. Ewen -- display sleep time - why 11 minutes https://bugs.launchpad.net/bugs/59589 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] [NEW] [Gutsy] Display sleep sets wrong DPMS off time
Public bug reported: Binary package hint: gnome-power-manager In Ubuntu Gutsy (7.10) with gnome-power-manager (2.20.0-0ubuntu6), the System->Preferences->Power Management slider for "Put display to sleep when inactive for" shows values that start with the value set in System->Preferences->Screensaver slider for "Regard the computer as idle after", and go upwards from there. Eg, if the Screensaver figure is set to 8 minutes, the minimum that the Power Manager display sleep can be set to is 8 minutes. However the value that is stored in the gnome configuration does not have this offset (eg, with the screensaver figure of 8 minutes, a power management display off figure of "13 minutes", the value stored in the gnome configuration will be 300 seconds (ie, 5 minutes). With a power management display off figure of "14 minutes" the value stored will be 360 seconds (ie, 6 minutes). The value from the gnome configuration is then applied as an X DPMS "power off" time, eg 300 seconds as the display time off. The result is that the monitor will then turn off after 5 minutes (300 seconds), even though the gnome power management display off time is reported through the user interface as "13 minutes". And thus the monitor turns off even before the screen saver kicks in, and much earlier than it was set to do so. The only combination that actually works sanely is to set both timeouts to the same value (0 minutes difference), which results in a DPMS off time of 0 seconds, which happens to display the automatic X server DPMS off time (leaving gnome power manager to do its own thing). This effect (idle time shown = screen saver time + power manager time; from https://bugs.launchpad.net/ubuntu/+source/gnome-power- manager/+bug/135813/comments/5) would appear to explain this bug: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/59589 too (ie, why the value cannot be set below 11 minutes -- they presumably have a screensaver time of 11 minutes). Obviously I expect that the time specified in gnome power manager to power off the display will be the time in reality, not some arbitrarily shorter time. (I first noticed this with a screen saver time of 8 minutes, and a display off time of 9 minutes -- which caused the screen to power down after 1 minute of inactivity.) There are various ways this could be fixed to work sanely: - have gnome-power-manager not set the X server DPMS time and manage everything itself, counting from when the screen saver kicks in - have gnome-power-manager set the X server DPMS time to the value stored plus the screen saver timeout (so the overall time is consistent with what is shown in the preferences dialog) - have the preferences dialog store the value shown into the gnome preferences (including the amount that is attributed to the screensaver timeout, eg the full 13 minutes == 780 seconds) so that the value can be set directly into the X server DPMS and will give the correct timeout - decouple the power manager and screen saver timeouts again, so that the power manager screen off time can be set from 1 minute upwards. This would also allow having the screen powered down before the screen is locked, which can be useful if one is doing something else nearby but wants to save power (eg, a power manager off time of 3 minutes, and a lock time of 5 minutes, would power the display down pretty rapidly but allow waking it with a keypress without having to type in a password). This would just require changing the power manager preferences UI to accurately report the figure it's setting into the gnome preferences. Ewen ** Affects: gnome-power-manager (Ubuntu) Importance: Undecided Status: New -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
Attached screenshot showing: - Screen Saver preference time of 8 minutes (480 seconds) - Power Manager display off time of 14 minutes (840 seconds) - gnome configuration apps->gnome-power-manager->timeout->sleep_display_ac value of 6 minutes (360 seconds; 14 minutes - 8 minutes = 6 minutes) - X DPMS information showing an off time of 360 seconds (6 minutes) Computer is on AC power at present. The values are live adjustable, and updating the slider in the power manager UI will result in new values being saved/set with the offset described above. Ewen ** Attachment added: "Example of DPMS off time being difference between power-manager off time and screensaver time" http://launchpadlibrarian.net/11849522/gnome-power-manager-dpms-time-incorrect.pngScreenshot.png -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
** Description changed: Binary package hint: gnome-power-manager In Ubuntu Gutsy (7.10) with gnome-power-manager (2.20.0-0ubuntu6), the System->Preferences->Power Management slider for "Put display to sleep when inactive for" shows values that start with the value set in System->Preferences->Screensaver slider for "Regard the computer as idle after", and go upwards from there. Eg, if the Screensaver figure is set to 8 minutes, the minimum that the Power Manager display sleep can be set to is 8 minutes. However the value that is stored in the gnome configuration does not have this offset (eg, with the screensaver figure of 8 minutes, a power management display off figure of "13 minutes", the value stored in the gnome configuration will be 300 seconds (ie, 5 minutes). With a power management display off figure of "14 minutes" the value stored will be 360 seconds (ie, 6 minutes). The value from the gnome configuration is then applied as an X DPMS "power off" time, eg 300 seconds as the display time off. The result is that the monitor will then turn off after 5 minutes (300 seconds), even though the gnome power management display off time is reported through the user interface as "13 minutes". And thus the monitor turns off even before the screen saver kicks in, and much earlier than it was set to do so. The only combination that actually works sanely is to set both timeouts to the same value (0 minutes difference), which results in a - DPMS off time of 0 seconds, which happens to display the automatic X + DPMS off time of 0 seconds, which happens to disable the automatic X server DPMS off time (leaving gnome power manager to do its own thing). This effect (idle time shown = screen saver time + power manager time; from https://bugs.launchpad.net/ubuntu/+source/gnome-power- manager/+bug/135813/comments/5) would appear to explain this bug: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/59589 too (ie, why the value cannot be set below 11 minutes -- they presumably have a screensaver time of 11 minutes). Obviously I expect that the time specified in gnome power manager to power off the display will be the time in reality, not some arbitrarily shorter time. (I first noticed this with a screen saver time of 8 minutes, and a display off time of 9 minutes -- which caused the screen to power down after 1 minute of inactivity.) There are various ways this could be fixed to work sanely: - have gnome-power-manager not set the X server DPMS time and manage everything itself, counting from when the screen saver kicks in - have gnome-power-manager set the X server DPMS time to the value stored plus the screen saver timeout (so the overall time is consistent with what is shown in the preferences dialog) - have the preferences dialog store the value shown into the gnome preferences (including the amount that is attributed to the screensaver timeout, eg the full 13 minutes == 780 seconds) so that the value can be set directly into the X server DPMS and will give the correct timeout - decouple the power manager and screen saver timeouts again, so that the power manager screen off time can be set from 1 minute upwards. This would also allow having the screen powered down before the screen is locked, which can be useful if one is doing something else nearby but wants to save power (eg, a power manager off time of 3 minutes, and a lock time of 5 minutes, would power the display down pretty rapidly but allow waking it with a keypress without having to type in a password). This would just require changing the power manager preferences UI to accurately report the figure it's setting into the gnome preferences. Ewen -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
lspci -vvnn on HP NC6220 laptop attached, as requested. ** Attachment added: "lspci -vvnn on HP NC6220" http://launchpadlibrarian.net/11928656/hp-nc6220-lspci-vvnn.txt -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
I can confirm that on a HP NC6220 after resume with the -generic Ubuntu Gutsy kernel (2.6.22-14.47) the internal speakers are mute (but playback to external speakers and/or headphones is fine). After reverting the patch mentioned earlier in this bug, at comment: https://bugs.launchpad.net/ubuntu/+source/linux- source-2.6.22/+bug/15/comments/1 the internal speakers work after suspend to RAM and resume (in fact the sound continues playing even before the screen is reset). Looking at the line that is re-enabled by reverting that patch, it appears that on the HP NC6220 the internal amplifier does not get powered on again unless the sound card is powered off at suspend time (without that it appears that whatever turns the power to the amplifier back on again doesn't get run when the sound card is powered up again in the resume code). Given the comment in the patch mentioned above I guess in some other laptops the power on code doesn't work at all, so if it's powered down it never gets powered up. So the best fix is probably to put that particular power down line under the control of a kernel module option, so on the HP NC6220, etc, the card can be properly powered down at suspend so it powers up fully at resume, but on other laptops where that causes problems the power down can be skipped. FTR (in case it helps someone else) it appears to be sufficient (after installing the packages needed to compile a kernel) to do: apt-get source linux-image-2.6.22-14-generic cd linux-source-2.6.22-2.6.22 cp /boot/config-`uname -r` .config make oldconfig make sound/pci/snd-intel8x0.ko make sound/pci/snd-intel8x0m.ko # Make a backup of the existing sound modules if desired then... cp -p sound/pci/snd*ko /lib/modules/`uname -r`/kernel/sound/pci/ and then reboot to use the new modules. Ewen -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
Ah, yes, I'd forgotten I'd done that: mkdir .tmp_versions (somewhere after cd'ing into the directory with the source and before running "make...".) After you run the mkdir you can just run "make " again, and it'll continue from where it left off. Apologies for the confusion. Ewen -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
This might seem really obvious, but you did make (the opposite of) change listed in this comment: https://bugs.launchpad.net/ubuntu/+source/linux- source-2.6.22/+bug/15/comments/1 before you built the modules, right? Ie, you have to uncomment the line: pci_set_power_state(pci, pci_choose_state(pci, state)); In the ..._suspend() function. (The change in that patch commented out the line, which is a call to control the power to the sound card -- the HP NC6220 appears to need that call for audio to work on resume.) If you just rebuild without making that change, you'll get exactly what shipped with Ubuntu Gutsy, which as we know doesn't work. If you didn't make that change, try making that change, rebuilding (run the "make ..." lines again and make sure it compiles sound/pci/intel8x0.c and the *.ko files again, then copy them back over and restart. (My list of things to do wasn't intended to be an exhaustive list of all the steps required, just to indicate that it wasn't necessary to fully rebuild the kernel -- which takes a long time -- only the modules.) Ewen -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Firefox: saved passwords causes crash with Mailman admin page
Public bug reported: Binary package hint: firefox The latest security update for Firefox for Ubuntu Dapper (6.06), version 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, now causes Firefox to crash repeatedly when using a saved password field on a Mailman admin login screen. This did not happen with the previous version (1.5.dfsg+1.5.0.8-0ubuntu0.6.06) or any previous version that I can recall. Other forms with saved passwords may also be affected (I initially thought that it was all saved forms, but it seems the one for launchpad.net isn't affected -- curious). Ubuntu Version: Dapper Drake (6.06) Firefox Version: 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, Reproducable: always How to reproduce: 1. Stop Firefox 2. Remove ~/.mozilla/firefox/PROFILE/signons.txt 3. Start Firefox 4. Go to http://somelistserver/mailman/admindb/mailman 5. Log in 6. Choose to allow Firefox to save the password 7. Observe Firefox crashes 8. Restart Firefox 9. Go back to http://somelistserver/mailman/admindb/mailman 10. Observe Firefox crashes again without displaying the page 11. Go back to step 2 and repeat. 12. Go back to step 2 and repeat choosing NOT to save the password at step 6 and observe Firefox doesn't crash Desired behaviour: As per previous version, should fill in saved password for the form and not crash. Other notes: It doesn't appear necessary for the password to actually be correct; just that it be saved. The crash on visiting the page with a saved password appears to happen aroun the time that the saved password might be pre-filled. Completely removing the saved passwords and starting again doesn't seem to help; as soon as the password is saved the problem reappears. Removing the firefox profile and starting again also doesn't seem to help; again as soon as the password is saved the problem reappears. The only thing I can see which is noticably different between the Mailman login page and, eg, the launchpad.net login page, in terms of saved passwords, is that the Mailman page is password-only, whereas the launchpad.net has an email address as well as the password. Possibly the bug is somehow related to the form being password-only. This behaviour is new with the security update for Ubuntu Dapper which came out this morning. I've used the saved password feature with many previous versions of Firefox without any problems. Knowing the issues which have been reported with Firefox recently, including a password stealing attack, I'd guess that there is a bug in the "fix" chosen to try to defeat that password stealing attack. Finally, for what little it seems to be worth, a backtrace of the coredump: [EMAIL PROTECTED]:/var/tmp$ gdb /usr/lib/firefox/firefox-bin core.10049 GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) Core was generated by `/usr/lib/firefox/firefox-bin -a firefox'. Program terminated with signal 11, Segmentation fault. [] #0 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7e56790 in raise () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x08055e0b in ?? () #3 0x000b in ?? () #4 0xbfaf0e8c in ?? () #5 0x in ?? () (gdb) Ewen ** Affects: firefox (Ubuntu) Importance: Undecided Status: Unconfirmed -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
Issolated test case: http://www.naos.co.nz/tmp/ubuntu/firefox/mailman-signon-page.html Steps to reproduce is slightly different here, I think because there's no real form processing behind it. To reproduce: 1. Go to URL 2Enter some string to be the password, eg "test" (it doens't matter, just needs something) 3. Choose to remember the password 4. Observe "success" message 5. Go back to URL (eg, click on the link in the success page) 6. Observe browser crashes 7. Restart firefox 8. Go to URL 9. Observe browser crashes 10. Remove ~/.mozilla/firefox/PROFILE/signons.txt 11. Start firefox 12. Go to URL 13. Observe browser doesn't crash 14. Repeat from 2 Test case (stripped down version of the Mailman admin page) is attached. The "success" page is just a stub HTML page with a link to this bug and back to the test case for convenience. Something like the launchpad.net signon form can serve as an example that doesn't crash. Ewen ** Attachment added: "Issolated test case (extracted from Mailman admin signon form)" http://librarian.launchpad.net/5593238/mailman-signon-page.html -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
As suggested by Peter Cherriman (https://launchpad.net/~pjcherriman) in comment: https://launchpad.net/ubuntu/+source/firefox/+bug/77859/comments/3 I've installed the firefox-dbg package (ie, debug symbols), and regenerated the core dump and run gdb over it. Like him I see: nsPasswordManager::AttachToInput (this=0x89f6368, aElement=0x0) at nsPasswordManager.cpp:1962 as the topmost item on the stack prior to the signal handler being invoked, so I too suspect that aElement=0x0 is somehow involved in the segmentation fault. Full gdb backtrace follows. Ewen -=- cut here -=- [EMAIL PROTECTED]:/var/tmp$ ulimit -c unlimited [EMAIL PROTECTED]:/var/tmp$ firefox & [1] 26943 [EMAIL PROTECTED]:/var/tmp$ [1]+ Segmentation fault (core dumped) firefox [EMAIL PROTECTED]:/var/tmp$ ls -l core* -rw--- 1 ewen ewen 55312384 2007-01-06 12:38 core.26943 [EMAIL PROTECTED]:/var/tmp$ gdb /usr/lib/firefox/firefox-bin core.26943 GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/ lib/tls/i686/cmov/libthread_db.so.1". Core was generated by `/usr/lib/firefox/firefox-bin -a firefox'. Program terminated with signal 11, Segmentation fault. warning: Can't read pathname for load map: Input/output error. Reading symbols from /usr/lib/firefox/libmozjs.so...Reading symbols from /usr/li b/debug/usr/lib/firefox/libmozjs.so...done. done. [] Loaded symbols for /usr/lib/firefox/components/libnkgnomevfs.so #0 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7d8d790 in raise () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x08055e0b in nsProfileLock::FatalSignalHandler (signo=-1210510412) at nsProfileLock.cpp:206 #3 #4 0xb67e65cc in nsPasswordManager::AttachToInput (this=0x89f6368, aElement=0x0) at nsPasswordManager.cpp:1962 #5 0xb67e7724 in nsPasswordManager::OnStateChange (this=0x89f6368, aWebProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsPasswordManager.cpp:948 #6 0xb5dd3e62 in nsDocLoader::FireOnStateChange (this=0x8205c88, aProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsDocLoader.cpp:1210 #7 0xb5dd3ea0 in nsDocLoader::FireOnStateChange (this=0x835a5b8, aProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsDocLoader.cpp:1217 #8 0xb5dd3ea0 in nsDocLoader::FireOnStateChange (this=0x86a6cd8, aProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsDocLoader.cpp:1217 #9 0xb5dd423b in nsDocLoader::doStopDocumentLoad (this=0x86a6cd8, request=0x86939b4, aStatus=0) at nsDocLoader.cpp:833 #10 0xb5dd4313 in nsDocLoader::DocLoaderIsEmpty (this=0x86a6cd8) at nsDocLoader.cpp:739 #11 0xb5dd45df in nsDocLoader::OnStopRequest (this=0x86a6cd8, aRequest=0x890d118, aCtxt=0x0, aStatus=0) at nsDocLoader.cpp:662 #12 0xb723ae35 in nsLoadGroup::RemoveRequest (this=0x86a6740, request=0x890d118, ctxt=0x0, aStatus=0) at nsLoadGroup.cpp:732 #13 0xb56c0c6e in nsDocument::UnblockOnload (this=0x88ff600) at nsDocument.cpp:5015 #14 0xb56e256a in DestroyImagePLEvent (aEvent=0x8a09438) at nsImageLoadingContent.cpp:668 #15 0xb7e40351 in PL_DestroyEvent (self=0x8a09438) at plevent.c:727 #16 0xb7e403bd in PL_HandleEvent (self=0x8a09438) at plevent.c:699 #17 0xb7e40b2e in PL_ProcessPendingEvents (self=0x80d3758) at plevent.c:623 #18 0xb7e41ed0 in nsEventQueueImpl::ProcessPendingEvents (this=0x80d3710) at nsEventQueue.cpp:417 #19 0xb68a3449 in event_processor_callback (source=0x8312d28, condition=G_IO_IN, data=0x0) at nsAppShell.cpp:67 #20 0xb77bc52c in g_vasprintf () from /usr/lib/libglib-2.0.so.0 #21 0xb77958d6 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #22 0xb7798996 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #23 0xb7798cb8 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #24 0xb7bc7765 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #25 0xb68a38da in nsAppShell::Run (this=0x814e778) at nsAppShell.cpp:139 #26 0xb67c33d2 in nsAppStartup::Run (this=0x814e738) at nsAppStartup.cpp:150 #27 0x0804f321 in XRE_main (argc=3, argv=0xbf82acf4, aAppData=0x80595e0) at nsAppRunner.cpp:2380 #28 0x0804abe4 in main (argc=0, argv=0x0) at nsBrowserApp.cpp:61 #29 0xb752bea2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 #30 0x0804ab31 in _start () at ../sysdeps/i386/elf/start.S:119 (gdb) -=- cut here -=- -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
Source for affected function that is segfaulting: void nsPasswordManager::AttachToInput(nsIDOMHTMLInputElement* aElement) { nsCOMPtr targ = do_QueryInterface(aElement); nsIDOMEventListener* listener = NS_STATIC_CAST(nsIDOMFocusListener*, this); targ->AddEventListener(NS_LITERAL_STRING("blur"), listener, PR_FALSE); targ->AddEventListener(NS_LITERAL_STRING("DOMAutoComplete"), listener, PR_FALSE); mAutoCompleteInputs.Put(aElement, 1); } (1956-1966 in firefox-1.5.dfsg+1.5.0.9/toolkit/components/passwordmgr/base/nsPasswordManager.cpp) The affected line, 1962, is: targ->AddEventListener(NS_LITERAL_STRING("blur"), listener, PR_FALSE); and appears to be segfaulting because the raw pointer inside targ is 0x0: (gdb) print targ $1 = { = {mRawPtr = 0x0}, } I _think_ that the raw pointer inside targ is null because atElement is null, but there's too much magic in the ns smart pointers to trace through without ever having seen the code before. Working back up the stack, the caller is: -=- cut here -=- (gdb) up #5 0xb67e7724 in nsPasswordManager::OnStateChange (this=0x89f6368, aWebProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsPasswordManager.cpp:948 948 AttachToInput(userField); (gdb) print userField $6 = { = {mRawPtr = 0x0}, } (gdb) -=- cut here -=- where the function contains the inline comment: -=- cut here -=- // We can auto-prefill the username and password if there is only // one stored login that matches the username and password field names // on the form in question. Note that we only need to worry about a // single login per form. -=- cut here -=- All of which tends to confirm my impression that the problem is prefilling in a save password on forms which have only a password field and no username field, Whatever changed in the code appears to no longer properly handle the situation where there is no username field and instead seems to assume that there'll be a username field to attach to if it finds a password field When it tries to attach to a non-existantant username field, thus dereferencing the null, it crashes. Ewen -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
I managed to find the source to firefox-1.5.dfsg+1.5.0.8 on a mirror (http://mirror.xmu.edu.cn/archive.ubuntu.com/ubuntu/pool/main/f/firefox/; it's already expired out of security.ubuntu.com and archive.ubuntu.com). Diff between firefox-1.5.dfsg+1.5.0.8 and firefox-1.5.dfsg+1.5.0.9 reveals that a guard on userField being non-null was removed between those two versions, viz: -=- cut here -=- @@ -941,20 +945,20 @@ } if (firstMatch && !attachedToInput) { - nsAutoString buffer; - - if (userField) { + AttachToInput(userField); + + if (prefillForm) { +nsAutoString buffer; if (NS_FAILED(DecryptData(firstMatch->userValue, buffer))) goto done; -=- cut here -=- (Full diff of that file below.) So since it appears to be fatal to call AttachToInput(NULL), it appears that the function has been "deliberately" changed to cause Firefox to crash when faced with a presaved form which has no username field. This seems to be undesirable. At very worst it should refuse to fill in the form and continue running; ideally it would continue the previous Firefox behaviour and fill in the form without fuss. There's nothing in the comments or changelog to explain why the guard on userField being non-null was removed. The entire changelog for .8 to .9 is: -=- cut here -=- firefox (1.5.dfsg+1.5.0.9-0ubuntu0.6.06) dapper-security; urgency=low * New upstream security update: - CVE-2006-6504, MFSA 2006-73: SVG Processing Remote Code Execution. - CVE-2006-6503, MFSA 2006-72: XSS by setting img.src to javascript: URI. - CVE-2006-6502, MFSA 2006-71: LiveConnect crash finalizing JS objects. - CVE-2006-6501, MFSA 2006-70: Privilege escallation using watch point. - CVE-2006-6497, CVE-2006-6498, CVE-2006-6499, MFSA 2006-68: Crashes with evidence of memory corruption. -- Kees Cook <[EMAIL PROTECTED]> Tue, 2 Jan 2007 11:23:28 -0800 -=- cut here -=- None of the CVE or MFSA documents referenced talk about the password manager or saved password exploits or appear to explain why this code was changed. Given other security discussion I'm aware of I assume it's part of an attempt to avoid the recently publicised password stealing attack through user-created forms being pre-filled. The list appears to come from here: http://www.mozilla.org/projects/security/known- vulnerabilities.html#firefox1.5.0.9 which is referenced from here: http://www.mozilla.com/en-US/firefox/releases/1.5.0.9.html which is the upstream announcement of 1.5.0.9. Most of the change in nsPasswordManager.cpp appears to have come from upstream (comparing diffs with and without the ubuntu dapper patches). However upstream 1.5.0.8 upstream also didn't have the guard on userField being non-NULL. That guard was being added by the ubuntu dapper patch in 1.5.0.8, but is not being added in 1.5.0.9. In particular we seem to have lost this patch: -=- cut here -=- * toolkit/components/passwordmgr/base/nsPasswordManager.cpp: Take patch from bz#235336 as suggested by Ian Jackson to allow password manager to work with sites that only have a password field, no username. -- Eric Dorland <[EMAIL PROTECTED]> Mon, 6 Feb 2006 23:10:29 -0500 -=- cut here -=- I'm not sure what "bz#235336" is or where it can be found, but I strongly suspect that it includes the guard on userField being non-null. So it appears that a combination of an upstream change and dropping a patch that allowed password manager to work with password-only forms has caused this crash. It also appears to me that upstream will have this bug (crash with saved passwords on forms with only a password field) if I'm reading their code correctly. Any chance we can have this "bz#235336" patch reapplied and/or the guard on userField back again, so password manager works with password only forms and firefox doesn't crash? Ewen -=- full 1.5.0.8 to 1.5.0.9 diff for nsPasswordManager.cpp -=- [EMAIL PROTECTED]:/var/tmp/ubuntu-dapper-firefox$ diff -u firefox-1.5.dfsg+1.5.0.{8,9}/toolkit/components/passwordmgr/base/nsPasswordManager.cpp --- firefox-1.5.dfsg+1.5.0.8/toolkit/components/passwordmgr/base/nsPasswordManager.cpp 2007-01-06 13:45:37.0 +1300 +++ firefox-1.5.dfsg+1.5.0.9/toolkit/components/passwordmgr/base/nsPasswordManager.cpp 2007-01-06 12:53:22.0 +1300 @@ -815,6 +815,10 @@ PRUint32 formCount; forms->GetLength(&formCount); + + // check to see if we should formfill. failure is non-fatal + PRBool prefillForm = PR_TRUE; + mPrefBranch->GetBoolPref("prefillForms", &prefillForm); // We can auto-prefill the username and password if there is only // one stored login that matches the username and password field names @@ -907,7 +911,7 @@ continue; } - if (!oldUserValue.IsEmpty()) { + if (!oldUserValue.IsEmpty() && prefillForm) { // The page has prefilled a username. // If it matches any of our saved usernames, prefill the password
[Bug 77859] Firefox: Regression: saved passwords: password only forms crash firefox (patch lost)
Found the patch that got lost: Mozilla Bugzilla 235336: https://bugzilla.mozilla.org/show_bug.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&id=235336 (was obvious once I guessed that "bz" == "Bugzilla" not "Baz"/"Bazzar" or similar.) And the relevant patch: https://bugzilla.mozilla.org/attachment.cgi?id=185577 referred to does indeed add the guard on userField being non-NULL. Please apply, modified as necessary to fit 1.5.0.9. Ewen -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
"patch -r" (r == reverse) will unapply a patch. In this case given there's only one line changed it's actually easier just to edit the file in a text editor and uncomment the line that was commented out. If you're new to linux you may find the rest of the steps challenging too, and might be better waiting for the next Ubuntu release (Hardy Heron) which should have the fix included. It's due to be released within about 6 weeks I believe. Ewen -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Patch for Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin
I've now modified the patch from Mozilla Bugzilla (linked earlier in this bug) to apply to Firefox 1.5.0.9 (as shipped with Ubuntu) and recompiled the Firefox package with the patch (which takes about 2 hours, and 1GB of disk space), and appear to have a non-broken version of Firefox that is able to handled saved passwords on forms with and without usernames (ie, properly fill them in, both Mailman's admin screen and Launchpad's login form seemed to work). The modified patch is attached. Perhaps someone at Ubuntu could verify that this patch makes sense, and if so apply it and rebuild the Firefox security update. (I'd offer to make my binary available for others to test, but as far as I can tell Firefox trademark restrictions prevent anyone distributing a non- authorised build, even if it's supposed to be more stable than the one it replaces.) Ewen ** Attachment added: "Firefox 1.5.0.9 password only forms fix" http://librarian.launchpad.net/5859913/firefox-1.5.0.9-saved-passwords-password-only.diff -- Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin
I can confirm that the Firefox package 1.5.dfsg+1.5.0.9-0ubuntu0.6.06.1 no longer crashes when presented with the Mailman admin form where there is a saved password. Thanks for pushing out updated packages. Ewen -- Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
In the hope that this will bring the bug to the firefox/security maintainers attention, I've changed the status to "confirmed" given (a) the number of bugs which have been marked as a duplicate of this bug, and (b) that several people have reported they can reproduce the bug. It would be nice to have some indication from the Firefox maintainer and/or the Ubuntu security folks as to when this regression introduced with the Dapper 1.5.0.9 package might be looked at. Ewen ** Changed in: firefox (Ubuntu) Status: Unconfirmed => Confirmed -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin
I've retitled the bug to make it clearer that (a) it's a regression, (b) it only affects Ubuntu Dapper, and (c) it's only the Firefox 1.5.0.9 security update which is affected. At this point I don't think we need any more "it doesn't crash for me, but I'm using some other browser version" reports. It's pretty clearly a flaw introduced with the security update and as far as I can tell affects everyone using Ubuntu Dapper with Firefox 1.5.0.9 and an affected webpage (password only form with saved passwords). Ewens ** Summary changed: - Saved passwords causes crash with Mailman admin (1.5.x) + Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin ** Description changed: Binary package hint: firefox + + [Edit: NOTE: This is a _regression_ in Firefox 1.5.0.9, released as a + security update for Ubuntu Dapper. Functionality that used to work + perfectly now causes the browser to crash hard. The problem appears to + be widely reproduced with the only people unable to reproduce it being + those using some other browser version.] The latest security update for Firefox for Ubuntu Dapper (6.06), version 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, now causes Firefox to crash repeatedly when using a saved password field on a Mailman admin login screen. This did not happen with the previous version (1.5.dfsg+1.5.0.8-0ubuntu0.6.06) or any previous version that I can recall. Other forms with saved passwords may also be affected (I initially thought that it was all saved forms, but it seems the one for launchpad.net isn't affected -- curious). Ubuntu Version: Dapper Drake (6.06) Firefox Version: 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, Reproducable: always How to reproduce: 1. Stop Firefox 2. Remove ~/.mozilla/firefox/PROFILE/signons.txt 3. Start Firefox 4. Go to http://somelistserver/mailman/admindb/mailman 5. Log in 6. Choose to allow Firefox to save the password 7. Observe Firefox crashes 8. Restart Firefox 9. Go back to http://somelistserver/mailman/admindb/mailman 10. Observe Firefox crashes again without displaying the page 11. Go back to step 2 and repeat. 12. Go back to step 2 and repeat choosing NOT to save the password at step 6 and observe Firefox doesn't crash Desired behaviour: As per previous version, should fill in saved password for the form and not crash. Other notes: It doesn't appear necessary for the password to actually be correct; just that it be saved. The crash on visiting the page with a saved password appears to happen aroun the time that the saved password might be pre-filled. Completely removing the saved passwords and starting again doesn't seem to help; as soon as the password is saved the problem reappears. Removing the firefox profile and starting again also doesn't seem to help; again as soon as the password is saved the problem reappears. The only thing I can see which is noticably different between the Mailman login page and, eg, the launchpad.net login page, in terms of saved passwords, is that the Mailman page is password-only, whereas the launchpad.net has an email address as well as the password. Possibly the bug is somehow related to the form being password-only. This behaviour is new with the security update for Ubuntu Dapper which came out this morning. I've used the saved password feature with many previous versions of Firefox without any problems. Knowing the issues which have been reported with Firefox recently, including a password stealing attack, I'd guess that there is a bug in the "fix" chosen to try to defeat that password stealing attack. Finally, for what little it seems to be worth, a backtrace of the coredump: [EMAIL PROTECTED]:/var/tmp$ gdb /usr/lib/firefox/firefox-bin core.10049 GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) Core was generated by `/usr/lib/firefox/firefox-bin -a firefox'. Program terminated with signal 11, Segmentation fault. [] #0 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7e56790 in raise () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x08055e0b in ?? () #3 0x000b in ?? () #4 0xbfaf0e8c in ?? () #5 0x in ?? () (gdb) Ewen -- Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.
[Bug 77859] Patch for Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin
I've now modified the patch from Mozilla Bugzilla (linked earlier in this bug) to apply to Firefox 1.5.0.9 (as shipped with Ubuntu) and recompiled the Firefox package with the patch (which takes about 2 hours, and 1GB of disk space), and appear to have a non-broken version of Firefox that is able to handled saved passwords on forms with and without usernames (ie, properly fill them in, both Mailman's admin screen and Launchpad's login form seemed to work). The modified patch is attached. Perhaps someone at Ubuntu could verify that this patch makes sense, and if so apply it and rebuild the Firefox security update. (I'd offer to make my binary available for others to test, but as far as I can tell Firefox trademark restrictions prevent anyone distributing a non- authorised build, even if it's supposed to be more stable than the one it replaces.) Ewen ** Attachment added: "Firefox 1.5.0.9 password only forms fix" http://librarian.launchpad.net/5859913/firefox-1.5.0.9-saved-passwords-password-only.diff -- Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin
I can confirm that the Firefox package 1.5.dfsg+1.5.0.9-0ubuntu0.6.06.1 no longer crashes when presented with the Mailman admin form where there is a saved password. Thanks for pushing out updated packages. Ewen -- Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
In the hope that this will bring the bug to the firefox/security maintainers attention, I've changed the status to "confirmed" given (a) the number of bugs which have been marked as a duplicate of this bug, and (b) that several people have reported they can reproduce the bug. It would be nice to have some indication from the Firefox maintainer and/or the Ubuntu security folks as to when this regression introduced with the Dapper 1.5.0.9 package might be looked at. Ewen ** Changed in: firefox (Ubuntu) Status: Unconfirmed => Confirmed -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin
I've retitled the bug to make it clearer that (a) it's a regression, (b) it only affects Ubuntu Dapper, and (c) it's only the Firefox 1.5.0.9 security update which is affected. At this point I don't think we need any more "it doesn't crash for me, but I'm using some other browser version" reports. It's pretty clearly a flaw introduced with the security update and as far as I can tell affects everyone using Ubuntu Dapper with Firefox 1.5.0.9 and an affected webpage (password only form with saved passwords). Ewens ** Summary changed: - Saved passwords causes crash with Mailman admin (1.5.x) + Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin ** Description changed: Binary package hint: firefox + + [Edit: NOTE: This is a _regression_ in Firefox 1.5.0.9, released as a + security update for Ubuntu Dapper. Functionality that used to work + perfectly now causes the browser to crash hard. The problem appears to + be widely reproduced with the only people unable to reproduce it being + those using some other browser version.] The latest security update for Firefox for Ubuntu Dapper (6.06), version 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, now causes Firefox to crash repeatedly when using a saved password field on a Mailman admin login screen. This did not happen with the previous version (1.5.dfsg+1.5.0.8-0ubuntu0.6.06) or any previous version that I can recall. Other forms with saved passwords may also be affected (I initially thought that it was all saved forms, but it seems the one for launchpad.net isn't affected -- curious). Ubuntu Version: Dapper Drake (6.06) Firefox Version: 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, Reproducable: always How to reproduce: 1. Stop Firefox 2. Remove ~/.mozilla/firefox/PROFILE/signons.txt 3. Start Firefox 4. Go to http://somelistserver/mailman/admindb/mailman 5. Log in 6. Choose to allow Firefox to save the password 7. Observe Firefox crashes 8. Restart Firefox 9. Go back to http://somelistserver/mailman/admindb/mailman 10. Observe Firefox crashes again without displaying the page 11. Go back to step 2 and repeat. 12. Go back to step 2 and repeat choosing NOT to save the password at step 6 and observe Firefox doesn't crash Desired behaviour: As per previous version, should fill in saved password for the form and not crash. Other notes: It doesn't appear necessary for the password to actually be correct; just that it be saved. The crash on visiting the page with a saved password appears to happen aroun the time that the saved password might be pre-filled. Completely removing the saved passwords and starting again doesn't seem to help; as soon as the password is saved the problem reappears. Removing the firefox profile and starting again also doesn't seem to help; again as soon as the password is saved the problem reappears. The only thing I can see which is noticably different between the Mailman login page and, eg, the launchpad.net login page, in terms of saved passwords, is that the Mailman page is password-only, whereas the launchpad.net has an email address as well as the password. Possibly the bug is somehow related to the form being password-only. This behaviour is new with the security update for Ubuntu Dapper which came out this morning. I've used the saved password feature with many previous versions of Firefox without any problems. Knowing the issues which have been reported with Firefox recently, including a password stealing attack, I'd guess that there is a bug in the "fix" chosen to try to defeat that password stealing attack. Finally, for what little it seems to be worth, a backtrace of the coredump: [EMAIL PROTECTED]:/var/tmp$ gdb /usr/lib/firefox/firefox-bin core.10049 GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) Core was generated by `/usr/lib/firefox/firefox-bin -a firefox'. Program terminated with signal 11, Segmentation fault. [] #0 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7e56790 in raise () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x08055e0b in ?? () #3 0x000b in ?? () #4 0xbfaf0e8c in ?? () #5 0x in ?? () (gdb) Ewen -- Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.
[Bug 77859] Firefox: saved passwords causes crash with Mailman admin page
Public bug reported: Binary package hint: firefox The latest security update for Firefox for Ubuntu Dapper (6.06), version 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, now causes Firefox to crash repeatedly when using a saved password field on a Mailman admin login screen. This did not happen with the previous version (1.5.dfsg+1.5.0.8-0ubuntu0.6.06) or any previous version that I can recall. Other forms with saved passwords may also be affected (I initially thought that it was all saved forms, but it seems the one for launchpad.net isn't affected -- curious). Ubuntu Version: Dapper Drake (6.06) Firefox Version: 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, Reproducable: always How to reproduce: 1. Stop Firefox 2. Remove ~/.mozilla/firefox/PROFILE/signons.txt 3. Start Firefox 4. Go to http://somelistserver/mailman/admindb/mailman 5. Log in 6. Choose to allow Firefox to save the password 7. Observe Firefox crashes 8. Restart Firefox 9. Go back to http://somelistserver/mailman/admindb/mailman 10. Observe Firefox crashes again without displaying the page 11. Go back to step 2 and repeat. 12. Go back to step 2 and repeat choosing NOT to save the password at step 6 and observe Firefox doesn't crash Desired behaviour: As per previous version, should fill in saved password for the form and not crash. Other notes: It doesn't appear necessary for the password to actually be correct; just that it be saved. The crash on visiting the page with a saved password appears to happen aroun the time that the saved password might be pre-filled. Completely removing the saved passwords and starting again doesn't seem to help; as soon as the password is saved the problem reappears. Removing the firefox profile and starting again also doesn't seem to help; again as soon as the password is saved the problem reappears. The only thing I can see which is noticably different between the Mailman login page and, eg, the launchpad.net login page, in terms of saved passwords, is that the Mailman page is password-only, whereas the launchpad.net has an email address as well as the password. Possibly the bug is somehow related to the form being password-only. This behaviour is new with the security update for Ubuntu Dapper which came out this morning. I've used the saved password feature with many previous versions of Firefox without any problems. Knowing the issues which have been reported with Firefox recently, including a password stealing attack, I'd guess that there is a bug in the "fix" chosen to try to defeat that password stealing attack. Finally, for what little it seems to be worth, a backtrace of the coredump: [EMAIL PROTECTED]:/var/tmp$ gdb /usr/lib/firefox/firefox-bin core.10049 GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) Core was generated by `/usr/lib/firefox/firefox-bin -a firefox'. Program terminated with signal 11, Segmentation fault. [] #0 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7e56790 in raise () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x08055e0b in ?? () #3 0x000b in ?? () #4 0xbfaf0e8c in ?? () #5 0x in ?? () (gdb) Ewen ** Affects: firefox (Ubuntu) Importance: Undecided Status: Unconfirmed -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
Issolated test case: http://www.naos.co.nz/tmp/ubuntu/firefox/mailman-signon-page.html Steps to reproduce is slightly different here, I think because there's no real form processing behind it. To reproduce: 1. Go to URL 2Enter some string to be the password, eg "test" (it doens't matter, just needs something) 3. Choose to remember the password 4. Observe "success" message 5. Go back to URL (eg, click on the link in the success page) 6. Observe browser crashes 7. Restart firefox 8. Go to URL 9. Observe browser crashes 10. Remove ~/.mozilla/firefox/PROFILE/signons.txt 11. Start firefox 12. Go to URL 13. Observe browser doesn't crash 14. Repeat from 2 Test case (stripped down version of the Mailman admin page) is attached. The "success" page is just a stub HTML page with a link to this bug and back to the test case for convenience. Something like the launchpad.net signon form can serve as an example that doesn't crash. Ewen ** Attachment added: "Issolated test case (extracted from Mailman admin signon form)" http://librarian.launchpad.net/5593238/mailman-signon-page.html -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
As suggested by Peter Cherriman (https://launchpad.net/~pjcherriman) in comment: https://launchpad.net/ubuntu/+source/firefox/+bug/77859/comments/3 I've installed the firefox-dbg package (ie, debug symbols), and regenerated the core dump and run gdb over it. Like him I see: nsPasswordManager::AttachToInput (this=0x89f6368, aElement=0x0) at nsPasswordManager.cpp:1962 as the topmost item on the stack prior to the signal handler being invoked, so I too suspect that aElement=0x0 is somehow involved in the segmentation fault. Full gdb backtrace follows. Ewen -=- cut here -=- [EMAIL PROTECTED]:/var/tmp$ ulimit -c unlimited [EMAIL PROTECTED]:/var/tmp$ firefox & [1] 26943 [EMAIL PROTECTED]:/var/tmp$ [1]+ Segmentation fault (core dumped) firefox [EMAIL PROTECTED]:/var/tmp$ ls -l core* -rw--- 1 ewen ewen 55312384 2007-01-06 12:38 core.26943 [EMAIL PROTECTED]:/var/tmp$ gdb /usr/lib/firefox/firefox-bin core.26943 GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/ lib/tls/i686/cmov/libthread_db.so.1". Core was generated by `/usr/lib/firefox/firefox-bin -a firefox'. Program terminated with signal 11, Segmentation fault. warning: Can't read pathname for load map: Input/output error. Reading symbols from /usr/lib/firefox/libmozjs.so...Reading symbols from /usr/li b/debug/usr/lib/firefox/libmozjs.so...done. done. [] Loaded symbols for /usr/lib/firefox/components/libnkgnomevfs.so #0 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7d8d790 in raise () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x08055e0b in nsProfileLock::FatalSignalHandler (signo=-1210510412) at nsProfileLock.cpp:206 #3 #4 0xb67e65cc in nsPasswordManager::AttachToInput (this=0x89f6368, aElement=0x0) at nsPasswordManager.cpp:1962 #5 0xb67e7724 in nsPasswordManager::OnStateChange (this=0x89f6368, aWebProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsPasswordManager.cpp:948 #6 0xb5dd3e62 in nsDocLoader::FireOnStateChange (this=0x8205c88, aProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsDocLoader.cpp:1210 #7 0xb5dd3ea0 in nsDocLoader::FireOnStateChange (this=0x835a5b8, aProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsDocLoader.cpp:1217 #8 0xb5dd3ea0 in nsDocLoader::FireOnStateChange (this=0x86a6cd8, aProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsDocLoader.cpp:1217 #9 0xb5dd423b in nsDocLoader::doStopDocumentLoad (this=0x86a6cd8, request=0x86939b4, aStatus=0) at nsDocLoader.cpp:833 #10 0xb5dd4313 in nsDocLoader::DocLoaderIsEmpty (this=0x86a6cd8) at nsDocLoader.cpp:739 #11 0xb5dd45df in nsDocLoader::OnStopRequest (this=0x86a6cd8, aRequest=0x890d118, aCtxt=0x0, aStatus=0) at nsDocLoader.cpp:662 #12 0xb723ae35 in nsLoadGroup::RemoveRequest (this=0x86a6740, request=0x890d118, ctxt=0x0, aStatus=0) at nsLoadGroup.cpp:732 #13 0xb56c0c6e in nsDocument::UnblockOnload (this=0x88ff600) at nsDocument.cpp:5015 #14 0xb56e256a in DestroyImagePLEvent (aEvent=0x8a09438) at nsImageLoadingContent.cpp:668 #15 0xb7e40351 in PL_DestroyEvent (self=0x8a09438) at plevent.c:727 #16 0xb7e403bd in PL_HandleEvent (self=0x8a09438) at plevent.c:699 #17 0xb7e40b2e in PL_ProcessPendingEvents (self=0x80d3758) at plevent.c:623 #18 0xb7e41ed0 in nsEventQueueImpl::ProcessPendingEvents (this=0x80d3710) at nsEventQueue.cpp:417 #19 0xb68a3449 in event_processor_callback (source=0x8312d28, condition=G_IO_IN, data=0x0) at nsAppShell.cpp:67 #20 0xb77bc52c in g_vasprintf () from /usr/lib/libglib-2.0.so.0 #21 0xb77958d6 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #22 0xb7798996 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #23 0xb7798cb8 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #24 0xb7bc7765 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #25 0xb68a38da in nsAppShell::Run (this=0x814e778) at nsAppShell.cpp:139 #26 0xb67c33d2 in nsAppStartup::Run (this=0x814e738) at nsAppStartup.cpp:150 #27 0x0804f321 in XRE_main (argc=3, argv=0xbf82acf4, aAppData=0x80595e0) at nsAppRunner.cpp:2380 #28 0x0804abe4 in main (argc=0, argv=0x0) at nsBrowserApp.cpp:61 #29 0xb752bea2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 #30 0x0804ab31 in _start () at ../sysdeps/i386/elf/start.S:119 (gdb) -=- cut here -=- -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
Source for affected function that is segfaulting: void nsPasswordManager::AttachToInput(nsIDOMHTMLInputElement* aElement) { nsCOMPtr targ = do_QueryInterface(aElement); nsIDOMEventListener* listener = NS_STATIC_CAST(nsIDOMFocusListener*, this); targ->AddEventListener(NS_LITERAL_STRING("blur"), listener, PR_FALSE); targ->AddEventListener(NS_LITERAL_STRING("DOMAutoComplete"), listener, PR_FALSE); mAutoCompleteInputs.Put(aElement, 1); } (1956-1966 in firefox-1.5.dfsg+1.5.0.9/toolkit/components/passwordmgr/base/nsPasswordManager.cpp) The affected line, 1962, is: targ->AddEventListener(NS_LITERAL_STRING("blur"), listener, PR_FALSE); and appears to be segfaulting because the raw pointer inside targ is 0x0: (gdb) print targ $1 = { = {mRawPtr = 0x0}, } I _think_ that the raw pointer inside targ is null because atElement is null, but there's too much magic in the ns smart pointers to trace through without ever having seen the code before. Working back up the stack, the caller is: -=- cut here -=- (gdb) up #5 0xb67e7724 in nsPasswordManager::OnStateChange (this=0x89f6368, aWebProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsPasswordManager.cpp:948 948 AttachToInput(userField); (gdb) print userField $6 = { = {mRawPtr = 0x0}, } (gdb) -=- cut here -=- where the function contains the inline comment: -=- cut here -=- // We can auto-prefill the username and password if there is only // one stored login that matches the username and password field names // on the form in question. Note that we only need to worry about a // single login per form. -=- cut here -=- All of which tends to confirm my impression that the problem is prefilling in a save password on forms which have only a password field and no username field, Whatever changed in the code appears to no longer properly handle the situation where there is no username field and instead seems to assume that there'll be a username field to attach to if it finds a password field When it tries to attach to a non-existantant username field, thus dereferencing the null, it crashes. Ewen -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
I managed to find the source to firefox-1.5.dfsg+1.5.0.8 on a mirror (http://mirror.xmu.edu.cn/archive.ubuntu.com/ubuntu/pool/main/f/firefox/; it's already expired out of security.ubuntu.com and archive.ubuntu.com). Diff between firefox-1.5.dfsg+1.5.0.8 and firefox-1.5.dfsg+1.5.0.9 reveals that a guard on userField being non-null was removed between those two versions, viz: -=- cut here -=- @@ -941,20 +945,20 @@ } if (firstMatch && !attachedToInput) { - nsAutoString buffer; - - if (userField) { + AttachToInput(userField); + + if (prefillForm) { +nsAutoString buffer; if (NS_FAILED(DecryptData(firstMatch->userValue, buffer))) goto done; -=- cut here -=- (Full diff of that file below.) So since it appears to be fatal to call AttachToInput(NULL), it appears that the function has been "deliberately" changed to cause Firefox to crash when faced with a presaved form which has no username field. This seems to be undesirable. At very worst it should refuse to fill in the form and continue running; ideally it would continue the previous Firefox behaviour and fill in the form without fuss. There's nothing in the comments or changelog to explain why the guard on userField being non-null was removed. The entire changelog for .8 to .9 is: -=- cut here -=- firefox (1.5.dfsg+1.5.0.9-0ubuntu0.6.06) dapper-security; urgency=low * New upstream security update: - CVE-2006-6504, MFSA 2006-73: SVG Processing Remote Code Execution. - CVE-2006-6503, MFSA 2006-72: XSS by setting img.src to javascript: URI. - CVE-2006-6502, MFSA 2006-71: LiveConnect crash finalizing JS objects. - CVE-2006-6501, MFSA 2006-70: Privilege escallation using watch point. - CVE-2006-6497, CVE-2006-6498, CVE-2006-6499, MFSA 2006-68: Crashes with evidence of memory corruption. -- Kees Cook <[EMAIL PROTECTED]> Tue, 2 Jan 2007 11:23:28 -0800 -=- cut here -=- None of the CVE or MFSA documents referenced talk about the password manager or saved password exploits or appear to explain why this code was changed. Given other security discussion I'm aware of I assume it's part of an attempt to avoid the recently publicised password stealing attack through user-created forms being pre-filled. The list appears to come from here: http://www.mozilla.org/projects/security/known- vulnerabilities.html#firefox1.5.0.9 which is referenced from here: http://www.mozilla.com/en-US/firefox/releases/1.5.0.9.html which is the upstream announcement of 1.5.0.9. Most of the change in nsPasswordManager.cpp appears to have come from upstream (comparing diffs with and without the ubuntu dapper patches). However upstream 1.5.0.8 upstream also didn't have the guard on userField being non-NULL. That guard was being added by the ubuntu dapper patch in 1.5.0.8, but is not being added in 1.5.0.9. In particular we seem to have lost this patch: -=- cut here -=- * toolkit/components/passwordmgr/base/nsPasswordManager.cpp: Take patch from bz#235336 as suggested by Ian Jackson to allow password manager to work with sites that only have a password field, no username. -- Eric Dorland <[EMAIL PROTECTED]> Mon, 6 Feb 2006 23:10:29 -0500 -=- cut here -=- I'm not sure what "bz#235336" is or where it can be found, but I strongly suspect that it includes the guard on userField being non-null. So it appears that a combination of an upstream change and dropping a patch that allowed password manager to work with password-only forms has caused this crash. It also appears to me that upstream will have this bug (crash with saved passwords on forms with only a password field) if I'm reading their code correctly. Any chance we can have this "bz#235336" patch reapplied and/or the guard on userField back again, so password manager works with password only forms and firefox doesn't crash? Ewen -=- full 1.5.0.8 to 1.5.0.9 diff for nsPasswordManager.cpp -=- [EMAIL PROTECTED]:/var/tmp/ubuntu-dapper-firefox$ diff -u firefox-1.5.dfsg+1.5.0.{8,9}/toolkit/components/passwordmgr/base/nsPasswordManager.cpp --- firefox-1.5.dfsg+1.5.0.8/toolkit/components/passwordmgr/base/nsPasswordManager.cpp 2007-01-06 13:45:37.0 +1300 +++ firefox-1.5.dfsg+1.5.0.9/toolkit/components/passwordmgr/base/nsPasswordManager.cpp 2007-01-06 12:53:22.0 +1300 @@ -815,6 +815,10 @@ PRUint32 formCount; forms->GetLength(&formCount); + + // check to see if we should formfill. failure is non-fatal + PRBool prefillForm = PR_TRUE; + mPrefBranch->GetBoolPref("prefillForms", &prefillForm); // We can auto-prefill the username and password if there is only // one stored login that matches the username and password field names @@ -907,7 +911,7 @@ continue; } - if (!oldUserValue.IsEmpty()) { + if (!oldUserValue.IsEmpty() && prefillForm) { // The page has prefilled a username. // If it matches any of our saved usernames, prefill the password
[Bug 77859] Firefox: Regression: saved passwords: password only forms crash firefox (patch lost)
Found the patch that got lost: Mozilla Bugzilla 235336: https://bugzilla.mozilla.org/show_bug.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&id=235336 (was obvious once I guessed that "bz" == "Bugzilla" not "Baz"/"Bazzar" or similar.) And the relevant patch: https://bugzilla.mozilla.org/attachment.cgi?id=185577 referred to does indeed add the guard on userField being non-NULL. Please apply, modified as necessary to fit 1.5.0.9. Ewen -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
"patch -r" (r == reverse) will unapply a patch. In this case given there's only one line changed it's actually easier just to edit the file in a text editor and uncomment the line that was commented out. If you're new to linux you may find the rest of the steps challenging too, and might be better waiting for the next Ubuntu release (Hardy Heron) which should have the fix included. It's due to be released within about 6 weeks I believe. Ewen -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
I've just attempted to reproduce it now, with the same results as you (ie, the DPMS off time isn't being set as it was previously). I wondered whether it had something to do with either s2ram, or adding a monitor on resume (eg, docking with an external monitor) but neither of those seem to be triggering it now. I'll keep an eye out for it happening again in the next couple of weeks (it's pretty obvious as the monitor starts turning off pretty soon after I stop typing), and if it does happen try to figure out a more precise sequence to get it into that situation. If I don't see it again, perhaps it got resolved by a recent update. Thanks for trying to reproduce it. Ewen -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
I think I've figured out how to trigger it. The computer in question is a laptop, with an external CRT connected via a docking station some of the time -- and all the times the DPMS Off: value has been incorrectly set, the laptop has been docked with the CRT connected. In order to trigger it I seem to need to: - boot up docked, with the CRT on - suspend to RAM - turn off the CRT - unsuspend (which is hit the power button in the case of this laptop) - while unsuspending, turn on the CRT (at the "right" time) In that situation I get: DPMS (Energy Star): Standby: 0Suspend: 0Off: 60 DPMS is Enabled Monitor is On or: DPMS (Energy Star): Standby: 0Suspend: 0Off: 300 DPMS is Enabled Monitor is On with the "Off:" time being set to the difference between the Power Mangement time and the Screensaver time. And if that time is non-zero, then playing with the adjusters seems to set the Off: time to the difference between the two (which definitely seems to be the wrong behaviour to me). So there appears to be two things going on: - there's something in Gnome (presumably Power Management) which is incorrectly setting the DPMS Off time to the difference between the Power Management off time and the Screensaver time (possibly when it notices a non-zero Off: time -- but irrespective, it's still doing the wrong thing: if it's going to set it, it should be to the total Power Management off time, or 0) - there's a race condition between the CRT waking up and the DPMS being reset to zero (possibly by some other power management program or task), where the DPMS setting doesn't "stick" until the CRT is ready to accept it (for which the fix is presumably to have the power management reapply the setting a little while, eg, 30 seconds, after either (a) unsuspend, or (b) the arrival of a new monitor. It appears once it becomes a non-zero value it's difficult to get the "reset to 0" behaviour back; I did manage it with one suspend (powering on the CRT a little earlier in the unsuspend), but other attempts still didn't reset it to zero (including ensuring the CRT was fully powered on before unsuspending). In case it matters, the laptop is a HP NC6220, which has Intel integrated graphics (Intel 915GM), with a HP docking station, and a Viewsonic E70 CRT connected to it. Anyway it seems to me that if the Gnome power manager is going to manage the display power off itself, it should probably be explicitly resetting the X DPMS Off: time (and others) to 0, and definitely never setting it to the difference between the screensaver time and the Power Management screen off time. That seems to be the core bug. Ewen -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
Resetting status to New since there is now (hopefully) a way for others to reproduce it. ** Changed in: gnome-power-manager (Ubuntu) Status: Invalid => New -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
Tested with Hardy Alpha 4 (x86 Desktop). The Gnome configuration (apps ->gnome-power-manager->timeout) still stores the difference between the screen saver time and the power management time, as in Gutsy. However I wasn't able to trigger the behaviour of the X11 DPMS off timeout being set to a non-zero amount even in half a dozen suspend-to-ram/resume cycles. So either the bug does not exist in Hardy, or it's much harder to trigger, or perhaps its difficult to trigger resuming from a Live CD boot. (It did seem that the resume in Hardy is noticeably faster, even off a Live CD, than in Gutsy, which I guess might change the circumstances of any race condition.) At this stage I think it's probably safe to assume that the issue is resolved in Hardy. (And I planned to upgrade to Hardy anyway, once it's released.) Ewen -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
** Description changed: Binary package hint: gnome-power-manager In Ubuntu Gutsy (7.10) with gnome-power-manager (2.20.0-0ubuntu6), the System->Preferences->Power Management slider for "Put display to sleep when inactive for" shows values that start with the value set in System->Preferences->Screensaver slider for "Regard the computer as idle after", and go upwards from there. Eg, if the Screensaver figure is set to 8 minutes, the minimum that the Power Manager display sleep can be - set to is 8 minutes. + set to is 9 minutes (8+1 minutes). However the value that is stored in the gnome configuration does not have this offset (eg, with the screensaver figure of 8 minutes, a power management display off figure of "13 minutes", the value stored in the gnome configuration will be 300 seconds (ie, 5 minutes). With a power management display off figure of "14 minutes" the value stored will be 360 seconds (ie, 6 minutes). The value from the gnome configuration is then applied as an X DPMS "power off" time, eg 300 seconds as the display time off. The result is that the monitor will then turn off after 5 minutes (300 seconds), even though the gnome power management display off time is reported through the user interface as "13 minutes". And thus the monitor turns off even before the screen saver kicks in, and much earlier than it was set to do so. The only combination that actually works sanely is to set both timeouts to the same value (0 minutes difference), which results in a DPMS off time of 0 seconds, which happens to disable the automatic X server DPMS off time (leaving gnome power manager to do its own thing). This effect (idle time shown = screen saver time + power manager time; from https://bugs.launchpad.net/ubuntu/+source/gnome-power- manager/+bug/135813/comments/5) would appear to explain this bug: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/59589 too (ie, why the value cannot be set below 11 minutes -- they presumably have a screensaver time of 11 minutes). Obviously I expect that the time specified in gnome power manager to power off the display will be the time in reality, not some arbitrarily shorter time. (I first noticed this with a screen saver time of 8 minutes, and a display off time of 9 minutes -- which caused the screen to power down after 1 minute of inactivity.) There are various ways this could be fixed to work sanely: - have gnome-power-manager not set the X server DPMS time and manage everything itself, counting from when the screen saver kicks in - have gnome-power-manager set the X server DPMS time to the value stored plus the screen saver timeout (so the overall time is consistent with what is shown in the preferences dialog) - have the preferences dialog store the value shown into the gnome preferences (including the amount that is attributed to the screensaver timeout, eg the full 13 minutes == 780 seconds) so that the value can be set directly into the X server DPMS and will give the correct timeout - decouple the power manager and screen saver timeouts again, so that the power manager screen off time can be set from 1 minute upwards. This would also allow having the screen powered down before the screen is locked, which can be useful if one is doing something else nearby but wants to save power (eg, a power manager off time of 3 minutes, and a lock time of 5 minutes, would power the display down pretty rapidly but allow waking it with a keypress without having to type in a password). This would just require changing the power manager preferences UI to accurately report the figure it's setting into the gnome preferences. Ewen ** Description changed: Binary package hint: gnome-power-manager In Ubuntu Gutsy (7.10) with gnome-power-manager (2.20.0-0ubuntu6), the System->Preferences->Power Management slider for "Put display to sleep when inactive for" shows values that start with the value set in System->Preferences->Screensaver slider for "Regard the computer as idle after", and go upwards from there. Eg, if the Screensaver figure is set to 8 minutes, the minimum that the Power Manager display sleep can be set to is 9 minutes (8+1 minutes). However the value that is stored in the gnome configuration does not have this offset (eg, with the screensaver figure of 8 minutes, a power management display off figure of "13 minutes", the value stored in the gnome configuration will be 300 seconds (ie, 5 minutes). With a power management display off figure of "14 minutes" the value stored will be 360 seconds (ie, 6 minutes). The value from the gnome configuration is then applied as an X DPMS "power off" time, eg 300 seconds as the display time off. The result is that the monitor will then turn off after 5 minutes (300 seconds), even though the gnome power management display off time
[Bug 59589] Re: display sleep time - why 11 minutes
I suspect the "11 minutes" minimum is coming from your system->preferences->screensaver being set to 11 minutes; the figure reported in the gnome power manager dialog seems to be offset by the screensaver amount (even though it doesn't seem to be implemented like that); I've reported a separate bug about this disparity between the UI and what actually happens: https://bugs.launchpad.net/ubuntu/+source/gnome-power- manager/+bug/190537 For now the best work around I can find is to set the gnome power manager display off timeout to be sufficiently large that the difference between that timeout and the screensaver timeout is the power off time that I actually want. Ewen -- display sleep time - why 11 minutes https://bugs.launchpad.net/bugs/59589 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] [NEW] [Gutsy] Display sleep sets wrong DPMS off time
Public bug reported: Binary package hint: gnome-power-manager In Ubuntu Gutsy (7.10) with gnome-power-manager (2.20.0-0ubuntu6), the System->Preferences->Power Management slider for "Put display to sleep when inactive for" shows values that start with the value set in System->Preferences->Screensaver slider for "Regard the computer as idle after", and go upwards from there. Eg, if the Screensaver figure is set to 8 minutes, the minimum that the Power Manager display sleep can be set to is 8 minutes. However the value that is stored in the gnome configuration does not have this offset (eg, with the screensaver figure of 8 minutes, a power management display off figure of "13 minutes", the value stored in the gnome configuration will be 300 seconds (ie, 5 minutes). With a power management display off figure of "14 minutes" the value stored will be 360 seconds (ie, 6 minutes). The value from the gnome configuration is then applied as an X DPMS "power off" time, eg 300 seconds as the display time off. The result is that the monitor will then turn off after 5 minutes (300 seconds), even though the gnome power management display off time is reported through the user interface as "13 minutes". And thus the monitor turns off even before the screen saver kicks in, and much earlier than it was set to do so. The only combination that actually works sanely is to set both timeouts to the same value (0 minutes difference), which results in a DPMS off time of 0 seconds, which happens to display the automatic X server DPMS off time (leaving gnome power manager to do its own thing). This effect (idle time shown = screen saver time + power manager time; from https://bugs.launchpad.net/ubuntu/+source/gnome-power- manager/+bug/135813/comments/5) would appear to explain this bug: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/59589 too (ie, why the value cannot be set below 11 minutes -- they presumably have a screensaver time of 11 minutes). Obviously I expect that the time specified in gnome power manager to power off the display will be the time in reality, not some arbitrarily shorter time. (I first noticed this with a screen saver time of 8 minutes, and a display off time of 9 minutes -- which caused the screen to power down after 1 minute of inactivity.) There are various ways this could be fixed to work sanely: - have gnome-power-manager not set the X server DPMS time and manage everything itself, counting from when the screen saver kicks in - have gnome-power-manager set the X server DPMS time to the value stored plus the screen saver timeout (so the overall time is consistent with what is shown in the preferences dialog) - have the preferences dialog store the value shown into the gnome preferences (including the amount that is attributed to the screensaver timeout, eg the full 13 minutes == 780 seconds) so that the value can be set directly into the X server DPMS and will give the correct timeout - decouple the power manager and screen saver timeouts again, so that the power manager screen off time can be set from 1 minute upwards. This would also allow having the screen powered down before the screen is locked, which can be useful if one is doing something else nearby but wants to save power (eg, a power manager off time of 3 minutes, and a lock time of 5 minutes, would power the display down pretty rapidly but allow waking it with a keypress without having to type in a password). This would just require changing the power manager preferences UI to accurately report the figure it's setting into the gnome preferences. Ewen ** Affects: gnome-power-manager (Ubuntu) Importance: Undecided Status: New -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
Attached screenshot showing: - Screen Saver preference time of 8 minutes (480 seconds) - Power Manager display off time of 14 minutes (840 seconds) - gnome configuration apps->gnome-power-manager->timeout->sleep_display_ac value of 6 minutes (360 seconds; 14 minutes - 8 minutes = 6 minutes) - X DPMS information showing an off time of 360 seconds (6 minutes) Computer is on AC power at present. The values are live adjustable, and updating the slider in the power manager UI will result in new values being saved/set with the offset described above. Ewen ** Attachment added: "Example of DPMS off time being difference between power-manager off time and screensaver time" http://launchpadlibrarian.net/11849522/gnome-power-manager-dpms-time-incorrect.pngScreenshot.png -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
** Description changed: Binary package hint: gnome-power-manager In Ubuntu Gutsy (7.10) with gnome-power-manager (2.20.0-0ubuntu6), the System->Preferences->Power Management slider for "Put display to sleep when inactive for" shows values that start with the value set in System->Preferences->Screensaver slider for "Regard the computer as idle after", and go upwards from there. Eg, if the Screensaver figure is set to 8 minutes, the minimum that the Power Manager display sleep can be set to is 8 minutes. However the value that is stored in the gnome configuration does not have this offset (eg, with the screensaver figure of 8 minutes, a power management display off figure of "13 minutes", the value stored in the gnome configuration will be 300 seconds (ie, 5 minutes). With a power management display off figure of "14 minutes" the value stored will be 360 seconds (ie, 6 minutes). The value from the gnome configuration is then applied as an X DPMS "power off" time, eg 300 seconds as the display time off. The result is that the monitor will then turn off after 5 minutes (300 seconds), even though the gnome power management display off time is reported through the user interface as "13 minutes". And thus the monitor turns off even before the screen saver kicks in, and much earlier than it was set to do so. The only combination that actually works sanely is to set both timeouts to the same value (0 minutes difference), which results in a - DPMS off time of 0 seconds, which happens to display the automatic X + DPMS off time of 0 seconds, which happens to disable the automatic X server DPMS off time (leaving gnome power manager to do its own thing). This effect (idle time shown = screen saver time + power manager time; from https://bugs.launchpad.net/ubuntu/+source/gnome-power- manager/+bug/135813/comments/5) would appear to explain this bug: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/59589 too (ie, why the value cannot be set below 11 minutes -- they presumably have a screensaver time of 11 minutes). Obviously I expect that the time specified in gnome power manager to power off the display will be the time in reality, not some arbitrarily shorter time. (I first noticed this with a screen saver time of 8 minutes, and a display off time of 9 minutes -- which caused the screen to power down after 1 minute of inactivity.) There are various ways this could be fixed to work sanely: - have gnome-power-manager not set the X server DPMS time and manage everything itself, counting from when the screen saver kicks in - have gnome-power-manager set the X server DPMS time to the value stored plus the screen saver timeout (so the overall time is consistent with what is shown in the preferences dialog) - have the preferences dialog store the value shown into the gnome preferences (including the amount that is attributed to the screensaver timeout, eg the full 13 minutes == 780 seconds) so that the value can be set directly into the X server DPMS and will give the correct timeout - decouple the power manager and screen saver timeouts again, so that the power manager screen off time can be set from 1 minute upwards. This would also allow having the screen powered down before the screen is locked, which can be useful if one is doing something else nearby but wants to save power (eg, a power manager off time of 3 minutes, and a lock time of 5 minutes, would power the display down pretty rapidly but allow waking it with a keypress without having to type in a password). This would just require changing the power manager preferences UI to accurately report the figure it's setting into the gnome preferences. Ewen -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
lspci -vvnn on HP NC6220 laptop attached, as requested. ** Attachment added: "lspci -vvnn on HP NC6220" http://launchpadlibrarian.net/11928656/hp-nc6220-lspci-vvnn.txt -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
I can confirm that on a HP NC6220 after resume with the -generic Ubuntu Gutsy kernel (2.6.22-14.47) the internal speakers are mute (but playback to external speakers and/or headphones is fine). After reverting the patch mentioned earlier in this bug, at comment: https://bugs.launchpad.net/ubuntu/+source/linux- source-2.6.22/+bug/15/comments/1 the internal speakers work after suspend to RAM and resume (in fact the sound continues playing even before the screen is reset). Looking at the line that is re-enabled by reverting that patch, it appears that on the HP NC6220 the internal amplifier does not get powered on again unless the sound card is powered off at suspend time (without that it appears that whatever turns the power to the amplifier back on again doesn't get run when the sound card is powered up again in the resume code). Given the comment in the patch mentioned above I guess in some other laptops the power on code doesn't work at all, so if it's powered down it never gets powered up. So the best fix is probably to put that particular power down line under the control of a kernel module option, so on the HP NC6220, etc, the card can be properly powered down at suspend so it powers up fully at resume, but on other laptops where that causes problems the power down can be skipped. FTR (in case it helps someone else) it appears to be sufficient (after installing the packages needed to compile a kernel) to do: apt-get source linux-image-2.6.22-14-generic cd linux-source-2.6.22-2.6.22 cp /boot/config-`uname -r` .config make oldconfig make sound/pci/snd-intel8x0.ko make sound/pci/snd-intel8x0m.ko # Make a backup of the existing sound modules if desired then... cp -p sound/pci/snd*ko /lib/modules/`uname -r`/kernel/sound/pci/ and then reboot to use the new modules. Ewen -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
Ah, yes, I'd forgotten I'd done that: mkdir .tmp_versions (somewhere after cd'ing into the directory with the source and before running "make...".) After you run the mkdir you can just run "make " again, and it'll continue from where it left off. Apologies for the confusion. Ewen -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
This might seem really obvious, but you did make (the opposite of) change listed in this comment: https://bugs.launchpad.net/ubuntu/+source/linux- source-2.6.22/+bug/15/comments/1 before you built the modules, right? Ie, you have to uncomment the line: pci_set_power_state(pci, pci_choose_state(pci, state)); In the ..._suspend() function. (The change in that patch commented out the line, which is a call to control the power to the sound card -- the HP NC6220 appears to need that call for audio to work on resume.) If you just rebuild without making that change, you'll get exactly what shipped with Ubuntu Gutsy, which as we know doesn't work. If you didn't make that change, try making that change, rebuilding (run the "make ..." lines again and make sure it compiles sound/pci/intel8x0.c and the *.ko files again, then copy them back over and restart. (My list of things to do wasn't intended to be an exhaustive list of all the steps required, just to indicate that it wasn't necessary to fully rebuild the kernel -- which takes a long time -- only the modules.) Ewen -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Patch for Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin
I've now modified the patch from Mozilla Bugzilla (linked earlier in this bug) to apply to Firefox 1.5.0.9 (as shipped with Ubuntu) and recompiled the Firefox package with the patch (which takes about 2 hours, and 1GB of disk space), and appear to have a non-broken version of Firefox that is able to handled saved passwords on forms with and without usernames (ie, properly fill them in, both Mailman's admin screen and Launchpad's login form seemed to work). The modified patch is attached. Perhaps someone at Ubuntu could verify that this patch makes sense, and if so apply it and rebuild the Firefox security update. (I'd offer to make my binary available for others to test, but as far as I can tell Firefox trademark restrictions prevent anyone distributing a non- authorised build, even if it's supposed to be more stable than the one it replaces.) Ewen ** Attachment added: "Firefox 1.5.0.9 password only forms fix" http://librarian.launchpad.net/5859913/firefox-1.5.0.9-saved-passwords-password-only.diff -- Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin
I can confirm that the Firefox package 1.5.dfsg+1.5.0.9-0ubuntu0.6.06.1 no longer crashes when presented with the Mailman admin form where there is a saved password. Thanks for pushing out updated packages. Ewen -- Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
In the hope that this will bring the bug to the firefox/security maintainers attention, I've changed the status to "confirmed" given (a) the number of bugs which have been marked as a duplicate of this bug, and (b) that several people have reported they can reproduce the bug. It would be nice to have some indication from the Firefox maintainer and/or the Ubuntu security folks as to when this regression introduced with the Dapper 1.5.0.9 package might be looked at. Ewen ** Changed in: firefox (Ubuntu) Status: Unconfirmed => Confirmed -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin
I've retitled the bug to make it clearer that (a) it's a regression, (b) it only affects Ubuntu Dapper, and (c) it's only the Firefox 1.5.0.9 security update which is affected. At this point I don't think we need any more "it doesn't crash for me, but I'm using some other browser version" reports. It's pretty clearly a flaw introduced with the security update and as far as I can tell affects everyone using Ubuntu Dapper with Firefox 1.5.0.9 and an affected webpage (password only form with saved passwords). Ewens ** Summary changed: - Saved passwords causes crash with Mailman admin (1.5.x) + Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin ** Description changed: Binary package hint: firefox + + [Edit: NOTE: This is a _regression_ in Firefox 1.5.0.9, released as a + security update for Ubuntu Dapper. Functionality that used to work + perfectly now causes the browser to crash hard. The problem appears to + be widely reproduced with the only people unable to reproduce it being + those using some other browser version.] The latest security update for Firefox for Ubuntu Dapper (6.06), version 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, now causes Firefox to crash repeatedly when using a saved password field on a Mailman admin login screen. This did not happen with the previous version (1.5.dfsg+1.5.0.8-0ubuntu0.6.06) or any previous version that I can recall. Other forms with saved passwords may also be affected (I initially thought that it was all saved forms, but it seems the one for launchpad.net isn't affected -- curious). Ubuntu Version: Dapper Drake (6.06) Firefox Version: 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, Reproducable: always How to reproduce: 1. Stop Firefox 2. Remove ~/.mozilla/firefox/PROFILE/signons.txt 3. Start Firefox 4. Go to http://somelistserver/mailman/admindb/mailman 5. Log in 6. Choose to allow Firefox to save the password 7. Observe Firefox crashes 8. Restart Firefox 9. Go back to http://somelistserver/mailman/admindb/mailman 10. Observe Firefox crashes again without displaying the page 11. Go back to step 2 and repeat. 12. Go back to step 2 and repeat choosing NOT to save the password at step 6 and observe Firefox doesn't crash Desired behaviour: As per previous version, should fill in saved password for the form and not crash. Other notes: It doesn't appear necessary for the password to actually be correct; just that it be saved. The crash on visiting the page with a saved password appears to happen aroun the time that the saved password might be pre-filled. Completely removing the saved passwords and starting again doesn't seem to help; as soon as the password is saved the problem reappears. Removing the firefox profile and starting again also doesn't seem to help; again as soon as the password is saved the problem reappears. The only thing I can see which is noticably different between the Mailman login page and, eg, the launchpad.net login page, in terms of saved passwords, is that the Mailman page is password-only, whereas the launchpad.net has an email address as well as the password. Possibly the bug is somehow related to the form being password-only. This behaviour is new with the security update for Ubuntu Dapper which came out this morning. I've used the saved password feature with many previous versions of Firefox without any problems. Knowing the issues which have been reported with Firefox recently, including a password stealing attack, I'd guess that there is a bug in the "fix" chosen to try to defeat that password stealing attack. Finally, for what little it seems to be worth, a backtrace of the coredump: [EMAIL PROTECTED]:/var/tmp$ gdb /usr/lib/firefox/firefox-bin core.10049 GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) Core was generated by `/usr/lib/firefox/firefox-bin -a firefox'. Program terminated with signal 11, Segmentation fault. [] #0 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7e56790 in raise () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x08055e0b in ?? () #3 0x000b in ?? () #4 0xbfaf0e8c in ?? () #5 0x in ?? () (gdb) Ewen -- Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.