33835 - Smoketest B.33 locks up mozilla when attempting to bring up single-signon dialog

Status: VERIFIED DUPLICATE of bug 33542

(Toolkit :: Form Manager, defect, P3)

Description

[Byron Servies]

Using nightly build 2000-03-29-08-M15 for macintosh I have repeatedly needed to 
kill mozilla (command-option-esc) after running step 2 of smoketest B.33.  I have 
given mozilla 32MB of RAM to use.

STEPS TO REPRODUCE:

	1. Install Mozilla using the sea archive
	2. Remove the documents/Mozilla folder and the Mozilla Registery
	3. Start Mozilla and create a new proile
	4. Open URL: <http://www.mozilla.org/quality/help/smoketests/> and scroll to 
test B.33
	5. Following the instructions for B.33, enter you first and last name as 
follows:
	5a.  Click in the First name field and type something
	5b.  Tab twice to the Last name field
	5c.  Type your last name but do not press return or tab when you are done.
	6. Following the instructions, select Tasks | Personal ... | Form .. | 
Capture ...

	7. Following the instructions, quit and restart mozilla
	8. Return to the smoketest page and perform step 2 of B.33.
	9. Observe that after selecting Form .. | Safe...  the browser does not 
display the single signon dialog, even after many minutes.


After step 6 I have seen 2 behaviors, though I am reporting the most common.  The 
most common behavior is to receive the password dialog box.  In this case, type 
your password and continue with the test.  Twice I have had mozilla lock up at 
this step.
	

MY SYSTEM CONFIGURATION:

Mozilla: 32MB RAM

Software overview
	Mac OS overview
		Finder:	8.6
		System:	8.6  US
		Active enabler:	None
		At Ease:	Not installed
		QuickTime:	4.0.3
		File sharing:	is on
	Note: No startup disk was selected.
Memory overview
	Disk cache:	5 MB
	Virtual memory:	161 MB
		Used on volume:	Macintosh HD
	Built-in memory:	160 MB
		Location            Size           Memory type
		Bottom      32 MB    SDRAM DIMM
		Top         128 MB   SDRAM DIMM
	Backside L2 cache:	1 MB
Hardware overview
	Machine ID:	312
	Model name:	PowerBook
	Keyboard type:	PowerBook G3 Keyboard with Inverted-T
	Processor info:	PowerPC G3
	Machine speed:	250 MHz
	FPU:	Built-in

Comment 1

[Stephen P. Morse]

This is not single-signon, it's autofill.

Looks like a dup of bug 33542.  However that bug is really blocked by 28466, yet 
the steps you performed here indicate that you were not stopped by 28466.  So 
the question is, why not?

*** This bug has been marked as a duplicate of 33542 ***

Comment 2

[Byron Servies]

I have see nthe behavior described in bug 28466, but it is infrequent.  The 
behaviors described in this bug, bug 28466, and bug 33542 occur for me every time 
I run the test, but I cannot predict which of the behaviors (e.g. how far I can 
get along the process) before the browser will hang.

I have also seen bug 28466 behavior on linux, but only once (same build as this 
bug report).

Comment 3

[Stephen P. Morse]

bservies, thanks for your comment about the frequency of bug 28466.  That 
explains why some people were seeing it and others not, and why Sarah reported 
that it was fixed and then reversed herself and said that it came back.  So you 
are validating my hypothesis in that report in which I now suspect that it might 
be timing related.

I'll add this coment to that bug report.

Comment 4

[sairuh (rarely reading bugmail)]

verif