11356 - Wallet Problem on "Never Save" for Form Settings

Status: VERIFIED DUPLICATE of bug 10456

(Core :: DOM: Core & HTML, defect, P3)

Description

[Matt_Kerr]

This may be a proxy/Necko related problem. Loading a form and checking the box
that pops up for "never save" for the form generates this in the Apprunner
console box:

** GetStringFromName: WantToCaptureForm?, Do you want to put the values on this
form into your wallet?
Reading file...
Reading file...Done

** GetStringFromName: NeverSave, Never save this form
onUpate
Do you want to put the values on this form into your wallet?
 setting message

 setting message
onUpate
Do you want to put the values on this form into your wallet?
 setting message
Never save this form
 setting message
Connect: Looking up host: people.netscape.com...
Connect: Looking up host: people.netscape.com...
Connect: Contacting host: people.netscape.com...

I believe the last bit was the proxy not working. I was loading the HTML source
from an intranet site, so I didn't expect it to try and go to
people.netscape.com.

After this all happened, Mozilla freezes up and only closing AppRunner.exe's
window will close the browser.

Comment 1

[karnaze (gone)]

Reassigning to Steve.

Comment 2

[Stephen P. Morse]

The access to people.netscape.com is normal -- we need to fetch some tables that
tell us how to interpret the field names found on forms.  But the fact that it
hung on accessing those files is not normal.  Are you able to access the
following location from the 5.0 browser executing within your firewall?  This is
one of the files that we are attempting to download.

   http://people.netscape.com/morse/wallet/FieldSchema.tbl

Comment 3

[Stephen P. Morse]

Actually this might be a dup of 6157.  Did you wait long enough for the download
to complete?

Comment 4

[Matt_Kerr]

I believe it didn't load because I hadn't put in my proxy settings yet. I just
tried using the Preferences menu item and it just brings up a blank window
filled with the picture of the windows and desktop behind it.

I'm using Mozilla build Milestone 8.5, that might mean a bit more. I didn't see
a place on the form to say that.

Why does the browser need to reach an external source for reading a local file?
It seems a bit silly. How could you properly view a form on an html on your own
computer, if you had your own web server and no net connection?

Maybe I should make a new bugzilla entry for the Preferences bug I encountered?

Comment 5

[leger]

Resetting Target Milestone from M8 to M9 since M8 is long gone :-)

Comment 6

[Stephen P. Morse]

You say you are using Milestone 8.5.  I know what M8 is but I have no idea what
M8.5 is.  M8 did not have necko.  Does your M8.5 have necko.  If so, that would
explain the problem.  Necko introduced bug 10456 which prevented the files in
question from being downloaded.  We have since put in a temporary patch to at
least get by this "hang".  You might have a version post-necko but pre-patch.
Try a current build and let me know if you are still seeing the problem.

I'm going to mark this as a dup of 10456.

Regarding your questions as to why we are downloading these files.  They are not
local files -- they are translation tables housed on the netcenter server (or at
least they will be in the final release).  These tables might change frequently
as we add better mapping rules and so we don't want them kept locally on the
client but rather want them to be downloaded once per browser session.  There
will be an initial local copy so that if you can't get a connection outside your
firewall, then you will use the local copy.  And that copy will get updated each
time a successfull download occurs.  Currently we hang if the download doesn't
finish but that is currently being changed.


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

Comment 7

[Matthew Tuck [:CodeMachine]]

If it's going to access these remote tables I'll assume there'll be a pref for
ppl who don't want this?

Comment 8

[Stephen P. Morse]

There'll probably be a pref specifying the URL of the server on which the files
are hosted.  This would allow ISP's to provide their own tables if they desire.
And setting this URL to null would simply not load any tables.