DESCRIPTION In the M5 release, going to http://archie.is.co.za/ftpsearch and submitting a query causes the program to go to people.netscape.com briefly, according to the apprunner DOS box. STEPS TO REPRODUCE 1. Start apprunner. 2. Go to http://archie.is.co.za/ftpsearch 3. Accept all the default settings, and run a search for any file (I searched for "mozilla.xul"). 4. Take a look at your apprunner DOS box -- what I saw is appended under ACTUAL RESULTS. ACTUAL RESULTS The browser seems to briefly go to people.netscape.com. Whilst it is there, the apprunner browser is COMPLETELY unresponsive - no buttons work, no menus work, cannot be closed or resized, nothing works at all. The following is displayed: Connect: Contacting host: wwwproxy.ru.ac.za:3128... Connect: Host people.netscape.com contacted. Waiting for reply... Transferring data from people.netscape.com Connect: Contacting host: wwwproxy.ru.ac.za:3128... Connect: Host people.netscape.com contacted. Waiting for reply... Transferring data from people.netscape.com Then, after about 10 seconds (or so), apprunner suddenly starts working again, and works normally. Incidentally, wwwproxy.ru.ac.za:3128 is my manual proxy. EXPECTED RESULTS The browser should not take a quick stop-off at people.netscape.com, it should finish my query with no delays. BUILD DATE and PLATFORM M5 release, Win95.

Updating QA Contact

I didn't see evidence of Apprunner going to people.netscape.com but Apprunner did take an unacceptable long time to load the search results page. Viewer did not take this long. Dave, can you take a look. Nisheeth I'm CCing you because I recall another bug involving web shell doc loading which you fixed (and which worked in Viewer but not Apprunner).

This going people.netscape.com thing appears to be due to the wallet. Surely this is not what is supposed to happen? I certainly don't want my saved credit card details to be stored on a remote server! Apprunner works ok with the wallet thing going off to people.netscape.com. On the other hand, this is completely killing viewer.exe, which goes off into an infinite loop of what appears to be trying to display a dialog box, which it can't, because it doesn't have a webshell (or whatever it is). A simplified test case is here: http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/formpost.html Note, by the way, that this only appears to happen if the form contains three or more fields. I am not sure why, presumably there is a good reason...

wallet problem? reassigning to morse.

The behavior is exactly what is expected -- there is no bug. I am closing this out as invalid. The sidetrip to people.netscape.com is to fetch tables used for decoding the meaning of field names. It does not send anything back so py8ieh's concern about his credit card numbers being stored on a remote server are unfounded. And this sidetrip occurs exactly once per brower session -- at the first time that wallet is used. In general, the delay is unnoticable, at least in the US. From abroad, such as South Africa (where the reporter of this bug is located) or the United Kindgom (where another one of the commentors is), the delay is probably longer. If it is long enough to be unacceptable, there are two options. First, you can disable wallet from the preference panel and then this access will never again be made. Second, you can hit the cancel button that will be displayed during the transfer (this will be implemented as soon as necko becomes stable -- currently necko has a serious problem whereby it is crashing during this transfer). The reason for the three-or-more fields is that wallet tries to make a determination if the form is significant enough to be saved. Certainly we don't want to save a form submitted to a search engine. So the heuristic used is that there are at least three input text fields on the form.

1. Can we not store this info locally? 2. Can the administrator set which database is searched? 3. If three text fields are required, how are username/password forms cached? Also, don't forget that we won't always be running on the internet - Mozilla might well run on a closed intranet or even on a stand alone machine. In both of these scenarios, people.netscape.com will be out of reach.

Good questions. Let me try and answer them. 1. Can we not store this info locally? That is what the latest version of seamonkey does. In fact, the fetch from the server is temporarily turned due to some things that got changed with the necko landing. But we do intend to turn it on again. The idea is that we can automatically update the local mapping tables and always keep them up to date. 2. Can the administrator set which database is searched? In the final version we intend to have a preference which specifies which server to fetch the data from. If you leave it blank, then no data is fetched. If some organization wishes to maintain there own tables inside their own firewall, then they can configure all their clients to use that server. 3. If three text fields are required, how are username/password forms cached? There are two distinct cachings going on here. One is the users wallet data such as name, address, phonenumber, etc which he enters on one form and wishes to have prefilled on some other form. In this case we don't want to cache short forms such as search requests. Hence the three-field heuristic. The second caching is for username/passwords. Here no attempt will ever be made to reuse values from one form onto another. They will be reused only on the form on which they were originally entered. The three field heuristic is not used in this case. Instead a check is made for a password field.

Very groovy!