28466 - Capture Form causes browser to hang

Status: VERIFIED FIXED

(Toolkit :: Form Manager, defect, P3)

Description

[sairuh (rarely reading bugmail)]

i know that as of the 2000021808 builds wallet stuff has been disabled --but i
found this using y'day's opt comm bits [2000021708], so this is a regression.

1. go to above URL.
2. fill out some of the fields.
3. go to Tasks > Autofill > Capture Form

result: browser hangs.
expected: browser shouldn't hang.

Comment 1

[Stephen P. Morse]

This is the same as the change-password problem for mac (bug 28148) whereby 
wallet functions cause browser to hang.  Problem occured when the netcenter 
tables were being downloaded.  In the case of change-password, the wallet tables 
really weren't needed yet, so I was able to bypass the problem by not 
downloading them (that was the fix for 28148).

But for the actual wallet functions, these tables are needed and have to be 
downloaded.  So I realized that the problem of downloading them on the mac would 
have to be eventually addressed, and it's good that you opened this bug report 
so I don't forget about the problem.  (Of course this won't affect beta because 
the menu items are missing, so that's why I designated this as M15.)

But I am interested in knowing if this is really a regression.  As of what build 
was this still working on the mac?  Knowing that will make it easier for me when 
I do address this problem.

Comment 2

[Stephen P. Morse]

Sarah, I need to know if this is still a problem on the mac or if it got fixed 
by later changes to the code?  Now that wallet is re-enabled, you should be able 
to easily test this.

Comment 3

[sairuh (rarely reading bugmail)]

no longer a problem for me --tested using tip build 2000.03.21.08-m15 (opt
comm). marking as wfm.

Comment 4

[sairuh (rarely reading bugmail)]

foo, it's back again, as of the opt comm build 2000.03.27.10. reopening.

Comment 5

[Stephen P. Morse]

Unable to reproduce.  We tried this on rjc's mac using a debug mozilla tree and 
it worked fine.  Sarah's hang was on with optimized mozilla bits.  Sarah will 
test this out on other machines to see if we can make some conclusions.

Comment 6

[sairuh (rarely reading bugmail)]

argh, using the same profile on the same mozilla (optimized, 2000.03.29.09) bits
on MacOS 9.0, i couldn't reproduce this problem just now. very annoying, since i
was able to repro it in front of steve just over an hour ago. feh.

however, i'm still able to reliably repro this when using the optimized
commercial bits (still 2000.03.29.09). got a MacsBug stack trace which i'll
attach.

Comment 7

[sairuh (rarely reading bugmail)]

Attachment: MacsBug trace from opt comm on OS 9.0

Comment 8

[sairuh (rarely reading bugmail)]

also reproducible on MacOS 8.6 (still using today's opt comm bits).

robert, i've attached a stack trace (obtained when voluntarily going into
MacsBug). the trace is identical btwn OS 8.6 and 9.0. i'll keep an eye when this
happens again on mozilla bits...

Comment 9

[Robert John Churchill]

cc'ing Warren, who says that he loves debugging these types of problems.

Comment 10

[Stephen P. Morse]

Note in bug 33835 that the reporter was able to successfully do the capture.  
And the fact that rjc could do it and even sairuh reported on two occaisons that 
it worked ok for her all leads me to believe that we are encountering an 
intermittent problem here -- probably timing related.  So my hunch is that we 
shouldn't be looking for a difference between debug versus optimized, or any 
other differences in the environments.  Rather we should do a test by repeating 
it many times in the same environment and see how consistent the results are.  
The will demonstrate if it's a timing problem.

Comment 11

[Stephen P. Morse]

In bug 33835 bservies describes the intermittent nature of the current bug.  
This further substantiates my hunch that we might have a timing-related problem 
here.

Comment 12

[Stephen P. Morse]

Furthermore, in bug 33835 bservies states that he was even able to observe this 
problem at least once on linux.  So this is not a mac-only bug although the 
timing must be such that it is more frequent on the mac.

Removing the pp indication.

Comment 13

[Simon Fraser [no longer active]]

morse, are you trying to download the wallet tables from netcenter synchronously? 
Is that what is causing this bug? If so, then you are violating a principle of 
necko that such downloads must be done asynchronously. We've had to fix a bunch 
of other cases like this already: ccing valeski, who knows more about this.

Comment 14

[Stephen P. Morse]

No, we are doing it asynchronously by using a local event loop.  Andreas wrote 
the code so perhaps he'll have more to say about this.

Comment 15

[Judson Valeski]

hmm, local event loop. why not just use the one on the UI thread (are you on
another thread?)?

Comment 16

[Stephen P. Morse]

I'll let andreas answer judson's question.

Here's another data point.  I am now seeing similar behavior on windows.  In 
particular, when I run with a sniffer, I find that about half the time the 
tables do not get downloaded.  The sniffer indicates that in the bad case, the 
http request is sent out but no response is ever received.  And this occurs 
randomly -- about half the times that I try it the tables are downloaded 
successfully and the other half there is no response.

Now of course this is different than the mac and linux cases when an outright 
hang occurred.  In this case we simply never get the response and so the local 
event loop never terminates.

Comment 17

[Andreas Otte]

Judson: Originally I planed to live on another thread with this file loads, 
start them as soon as possible (even before the ui thread exists) and join them 
at the latest possible moment. But that did not work, necko does not allow that 
(remember TestNeckoThread?).

We have to be sure that the files are loaded (or updated) when certain functions 
are called. Synchronous loads were not working at that time, and this solution 
was a temporary fix for the problem to unblock the wallet feature. If there are 
now better solutions to this problem please share your knowledge.

Comment 18

[Stephen P. Morse]

Don't know how to fix this one yet so it's not going to make m15.

Comment 19

[sairuh (rarely reading bugmail)]

strangely enough, i was able to get this to work on today's opt comm bits,
2000.04.12.12-M16. (didn't work on the M15 bits, though.)

Comment 20

[sairuh (rarely reading bugmail)]

ack, now i can get this happens all the time on linux. tested with the optimized
commercial bits 2000.04.17.05-m15.

will check the m16 bits once they're out.

Comment 21

[Stephen P. Morse]

Sarah, please confirm that (1) this is still a problem, and (2) it is cross 
platform.  Thanks.

Comment 22

[sairuh (rarely reading bugmail)]

hey...this...works...on linux and mac (and winNT), using 2000.05.09.08 optimized
commercial bits. i tried this using an existing (week-old) profile. i am
baffled. steve, any idea what made this magically work?

have people seen this work on mozilla (linux, mac) recently?

Comment 23

[sairuh (rarely reading bugmail)]

also works fine on today's linux and mac mozilla bits.

Comment 24

[Andreas Otte]

This seems to happen totaly randomly, must be some nasty timing problem. Ugly
stuff ...

Comment 25

[Simon Fraser [no longer active]]

...just as you would expect with the necko sync load threading problem. This bug 
won't magically go away, I think.

Comment 26

[Judson Valeski]

see 22103 for a patch I provided to try and move us beyond the sync load
problem. I was reluctant to try anything because we simply should not be doing
sync loads in most cases, but the changeover ain't gonna happen.

Comment 27

[leger]

Putting on [nsbeta2-] radar. Come back to PDT if you get a reproducible 
testcase.

Comment 28

[Stephen P. Morse]

This is probably being caused by bug 22103

Comment 29

[Stephen P. Morse]

Sarah, please try this out once again.  Several things have changed recently 
that might affect this.  For one, the prefill problem that started happening 
this week is now fixed so that should no longer get in the way here.  For 
another, I changed the way I download the server tables and that might have been 
a factor.  I'm anxiously awaiting your response.  Do repeated testing on it 
because it seems to have been an intermittent failure in the past.

Comment 30

[sairuh (rarely reading bugmail)]

using opt commercial bits on linux, mac and winNT. 2000.05.12.08.

1. testing bug 28466, Capture Data from Form, starting with a new profile, eg,
called "blah":
a. winNT: works, but the field names are
"www.mozilla.org/wallet/samples/inte..."
b. linux and mac: fail.

2. testing bug 28466, Capture Data from Form, using an existing profile (namely
"blah"):
a. retested linux and mac: somehow managed to work! and as in (1a) with the long
fieldnames.
b. winNT retested (restarted the browser before this retest): works, but now
this 2nd set of fieldnames are more reasonable, ie, "name.first," "name.last."

3. testing bug 33542, prefilling form w/stored data, using "blah":
a. winNT: works, but data confirmation dialog only displays values captured from
(2b).
b. linux and mac: fails --prolly because of the fieldname issues from (2a).

Comment 31

[Stephen P. Morse]

Together with dp, I made some changes that eliminate the local thread that was 
used while the wallet tables were being downloaded.  Also we now use local 
copies of the files if the download fails (that's what was causing the strange 
field names sairuh was reporting on in her last comment above).

Marking as fixed and hoping that sairuh's verification on Monday will confirm 
that.

Comment 32

[sairuh (rarely reading bugmail)]

no longer hangs. :-) tested using opt comm bits 2000.05.18.08 on linux, mac [and
winNT].