[Bug 77859] Re: Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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)

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

** 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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

** 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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

"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

[Ewen McNeill]

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

[Ewen McNeill]

"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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

** 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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

** 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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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)

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

** 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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

** 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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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)

[Ewen McNeill]

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

[Ewen McNeill]

"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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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)

[Ewen McNeill]

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

[Ewen McNeill]

"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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

** 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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

** 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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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

[Ewen McNeill]

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.