Wallet tables not updated from netcenter

VERIFIED WORKSFORME

Status

()

Toolkit
Form Manager
P3
major
VERIFIED WORKSFORME
18 years ago
9 years ago

People

(Reporter: Stephen P. Morse, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3-])

(Reporter)

Description

18 years ago
In the netscape product, the wallet tables do not get updated from the 
netcenter server.

The crash is caused by the fact that the wallet code is expecting a MODIFIED: 
header to be returned from netcenter so that it can record the time and use it 
in future if-modified-since requests.  The lack of the MODIFIED: header is 
causing a null pointer to be dereferenced, hence the crash.  That I can (and 
will) fix.

The lack of the MODIFIED: header will prevent using if-modified-since requests 
and that means that the table will be downloaded every time, whether it has 
changed or not.  This will probably have to be fixed on the netcenter end.

And one more problem here.  It looks like the format of the table that netcenter 
would send (had there not been a crash) is wrong.  It uses CR CR CR LF as 
linebreaks.  Not sure yet how much that will upset the parsing of the file that 
the wallet code is doing.  Will know more after I fix the crash bug.

To demonstrate the crash do the following:

1. start browser with a fresh profile
2. from menu go to tasks->privacy->form-manager->samples and click on any sample
3. from context menu select prefill-form

crash occurs.
(Reporter)

Comment 1

18 years ago
It's worse than I thought.  I have a fix for the crash and tried it again.  The 
file that is getting downloaded is shown below.  That ain't gonna work!!!!!

<HTML>
<HEAD>
<SCRIPT LANGUAGE=JavaScript>
<!--
var url = "http://home.netscape.com/wallet/wallet1.html";

if(navigator.appName.indexOf("Netscape")!=-1) { 
if(parseInt(navigator.appVersion) >= 3) { location.replace(url); } }
if(navigator.appName.indexOf("Microsoft")!=-1) { 
if(parseInt(navigator.appVersion) >= 4) { location.replace(url); } }
//-->
</SCRIPT>

<!-- REPLACE URL BELOW ALSO -->
<META HTTP-EQUIV=REFRESH CONTENT="0; 
URL=http://home.netscape.com/wallet/wallet1.html">
</HEAD>
</HTML>

Keywords: nsonly
(Reporter)

Comment 2

18 years ago
1. Problem is due to the redirect that netcenter is doing.  This works fine when 
a file is fetched with our networking layer since it automatically re-requests 
the file at the new location.  But my wallet code does not have a full 
networking layer support in it -- it simply requests a file directly and accepts 
whatever is sent back.  In other words, it doesn't parse the response headers to 
determine that the file was not received but rather what was received was an 
indication of where the file was moved to.

2. As a work-around to the redirect problem I modified the wallet.Server entry 
in the navigator.properties file so that instead of

   wallet.Server=http://home.netscape.com/bookmark/6_0b1/

it is

   wallet.Server=http://home.netscape.com/wallet/

3. With the above work-around in place, I was able to get the true wallet table.  
But it now contained CR CR LF as line separators.  This did indeed upset my 
parser which was then unable to decompose it into the individual wallet tables.
Severity: normal → major
Status: NEW → ASSIGNED
Keywords: nsbeta3
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
(Reporter)

Comment 3

18 years ago
Just checked in a fix for the crash.  Removing "crash" from summary.

However we still have the other problems noted here, namely the redirect problem 
and the line-terminator problem.  Both of these are preventing the wallet tables 
from being updated.
(Reporter)

Updated

18 years ago
Summary: Wallet tables not updated from netcenter -- caused a crash → Wallet tables not updated from netcenter
(Reporter)

Comment 4

18 years ago
And we still have the problem of the missing MODIFIED: header which no longer 
crashes but it does prevent us from using if-modified-since requests.  So to 
summarize, there are three items that prevent the wallet tables from being 
updated from netcenter:

1. redirects on the url being fetched
2. invalid line terminators in file that is downloaded
3. no MODIFIED: header received when file is downloaded

cc:ing andreas on this in case he has any comments on the MODIFIED header 
problem before he leaves for vacation.

Comment 5

18 years ago
Hmmm ... I will look into it. It seems to me this is no real redirect to the
data but a redirect to a 404 page and it reports back a 404 status. We can work
with that status and display a message saying "Unable to load the wallet
tables!" or something like that instead of reading that stuff in as wallet
tables.

Comment 6

18 years ago
1. I just noticed my previous comment is wrong. There is no 404, I was testing a
wrong url. A redirect is absolutly deadly in this case. Anyway: The file that is
getting downloaded is no html file. Why call it that? This may confuse server
and client/mime converters in what to expect or to send. You should definitly
use a non standard extension like tbl or something similar. This is raw data
without any more style information! Treat it as that.

2. It seems to me someone forgot to use dos2unix on the file.

3. As to the missing last-modified response header: The server should return it
when asked with if-modified-since (at least to my knowledge). Could be that
someone wants to prevent caching on netcenter side. This should definitly be
fixed there.
(Reporter)

Comment 7

18 years ago
In order of importance, the missing header must get added and quickly.  Although 
I have fixed the trunk so that it no longer crashes, the missing header will 
still cause the beta2 release to crash.  That is serious!!!!  Sairuh, can you 
test a beta2 commercial release and confirm this?  The steps to reproduce are 
given in the bug description way above.

We are fortunate in this case in that we can fix a beta2 crash without having to 
change the bits on the wire.  All we need to do is change the behavior of the 
netcenter server.
sorry for the delay --was at Linuxworld and Mozilla Dev conferences much of last
week.

anyhow, went thru the original steps using pr2 [2000.08.07.12 commercial branch
bits] on winNT (except that prefill form wasn't in the context menu, so i
selected it from the tasks>blah blah menu). didn't get a crash using a fresh
profile --got the alert that there are no fields to be prefilled, expected since
i hadn't captured anything yet. :)
(Reporter)

Comment 9

18 years ago
Can you try it a second time.  With a fresh profile you get the default wallet 
tables on the first run.  And during that run the netcenter tables are being 
fetched.  You then need to exit and reenter the browser and do the above steps a 
second time.  Then the downloaded tables will be used and that's when you'll see 
the crash.
(Reporter)

Comment 10

18 years ago
Ignore my comment above.  The crash should occur on the first run because that 
is when the file is being downloaded and that is when the test for the MODIFIED: 
header is made.  So I'm surprised that pr2 is not crashing and I can't explain 
why that would be so.
(Reporter)

Comment 11

18 years ago
The reason why sarah didn't see the crash is because she is running an optimized 
build.  The crash occurs on debug builds only.  What is happening is that the 
wallet code attempts to set a null character pref and it does it by winding its 
way down into prefapi.c.  In the pref_SetValue routine in that module is the 
line:

   PR_ASSERT(newValue.stringVal);

That gets us to the PR_Assert routine in prlog.c which crashes in some code that 
is for debugging only.  If that code is skipped, there is no crash and the 
browser continues to execute normally.

So that's a bit of good news.  No crash on the released pr2 bits anyway.  And we 
don't need to be concerned about the debug bits corresponding to pr2.

I just filed bug 49776 for the crash in the assert.
Are you sure it was a crash? NSPR's PR_Assert() purposefully calls abort().
(Reporter)

Comment 13

18 years ago
My mistake, it was an abort not a crash.  I got misled because when I tried to 
resume from the supposed crash I got the "abnormal program termination" popup 
box and I mistook that for a crash.

However that's quite a severe action for NSPR to be taking.  Why should they 
abort on an assert?  I'll comment further on that in bug 49776.
They abort because they have always aborted. There are severe religious 
differences about what an assert means, witness some of the battles about how 
NS_ASSERTION should behave in n.p.m.xpcom.
(Reporter)

Comment 15

18 years ago
There's nothing more that I can do about this on the client side.  Remainder of 
this fix will have to be done by netcenter.  Reassigning bug to Reed.
Assignee: morse → reed
Status: ASSIGNED → NEW
Keywords: netcenter
(Reporter)

Comment 16

18 years ago
OK, Reed did his thing and now it's back in my court.  Here's the status:

1. Reed had netcenter fix the line-termination problem
2. MODIFIED: header problem was solved by renaming the file on netcenter 
from a .tbl file to a .html file
3. Redirect can be fixed by having browser go directly to the redirected 
location.

So now I must do the following in order to close this out:

1. Check that the line terminators on netcenter are correct
2. Change the file name so that it is a .tbl file
3. Change hard-coded location in browser to be the redirected one

All this I can do with no further netcenter involvement.  Thanks Reed.
Assignee: reed → morse
(Reporter)

Comment 17

18 years ago
Done.  I did the following:

- I verified that the linebreaks are indeed a single LF and no CR's
- I changed the name of the table from wallet1.html to wallet.tbl
- I modified the server location to be http://home.netscape.com/wallet/
- I observed that the MODIFIED: header is indeed being returned

And, most importantly, after making my changes above I then ran a test and saw 
that the wallet tables were being downloaded from netcenter and that the wallet 
functions were working correctly with these downloaded tables.

QA: to verify that this is working, do the following:

0. Get a fresh profile.

1. Remove all *.tbl files from your defaults directory.  This will cause wallet 
to fail if it can't download the tables from netcenter.

2. Start browser, go to any sample form and right-click "prefill".  This will 
cause the tables to be downloaded.  But they won't be used until the next 
session.

3. Exit and reenter browser.  Now the downloaded tables will get used.

4. Bring up sample 10, fill in first name and last name, save the data

5. Bring up sample 1.  Note it contains a field for name, rather than separate 
fields for first and last name as sample 10 did.

6. Do a prefill.  If wallet tables aren't present, there is no way that wallet 
would know that the name field is the concatenation of first and last name.  So 
if this name field gets filled in correctly, then the wallet tables are present 
and being used.  Since you deleted the default wallet tables in step 1, the only 
way the wallet tables could be present now is if they were downloaded from 
netcenter.

Conclusion: If the name field in step 6 gets filled in correctly, then the 
wallet tables must have been successfully downloaded from netcenter.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
tested using 2000.09.05.04 optimized comm bits on linux. i followed the steps
steve outlined at 2000-08-28 22:04. unfortunately, i was unable to prefill at
step 6 (got the "no fields to be prefilled" error). as a double check, i looked
at the form data dialog and the field name for both the last and first names i
entered (in step 4) both begin with "communicator/locale/wallet/sample10.ht..."

just to be clear, at step 1 i did delete all the *.tbl files in
package/defaults/wallet/ --but not by rm, i simply moved them into another
directory (i created foo/ under package/defaults/wallet/ and moved 'em there).
would that suffice?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 19

18 years ago
Yes, moving them to another directory would suffice.

I just tried this using a mozilla build and it worked fine.  So there must still 
be some problem on the netcenter server.  I'm building a commercial tree right 
now and will try it out.
Status: REOPENED → ASSIGNED
(Reporter)

Comment 20

18 years ago
This works fine for me in a commercial build as well.  So both the 
mozilla tables and the netcenter tables are indeed being downloaded and used.

Sarah, why isn't it working for you? Are you sure that you exited and reentered 
the browser (step 3).  The tables that are downloaded are not used on the 
current browser session so you need to exit and reenter in order to get to them.

Do you see any *.tbl files in your profile directory.  After doing the "prefill" 
of step 2, you should see the file wallet.tbl.  After doing the "capture" of 
step 4, you should have the following four additional *.tbl files:

   URLFieldSchema.tbl
   FieldSchema.tbl
   SchemaConcat.tbl
   DistinguishedSchema.tbl
sorry about the delay... testing now with 2000.09.08.08 [linux opt comm].

yep, i quit and restarted the browser. after step 3 (but before step 4), i don't
see *any* .tbl files in my profile dir. after step 4, i still don't see any
*.tbl files, although a *.w file is created.

also still fail to prefill form 1 (step 6), same error as i previously reported.
Per PDT rules P3 bugs are now nsbeta3-
Whiteboard: [nsbeta3+] → [nsbeta3-]
spam: mass-moving open password manager (single signon) and form manager
(autofill) bugs to Terri for qa contact. unfortunately, i cannot cc myself with
this form, so feel free and add me if you want to keep me in the loop with any
(but, pls not all :) of these... will also go thru 'em meself, a bit later...
QA Contact: sairuh → tpreston
(Reporter)

Comment 24

17 years ago
I never have been able to reproduce this bug.  Closing as works-for-me.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → WORKSFORME

Comment 25

17 years ago
I as well, have never been able to reproduce this bug
Status: RESOLVED → VERIFIED
Assignee: morse → nobody
Component: Form Manager → Form Manager
Product: Core → Toolkit
QA Contact: tpreston → form.manager
Target Milestone: M18 → ---
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.