Closed Bug 49189 Opened 25 years ago Closed 25 years ago

Wallet tables not updated from netcenter

Categories

(Toolkit :: Form Manager, defect, P3)

Product:
Toolkit
Component:
Form Manager
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: morse, Unassigned)

Details

(Whiteboard: [nsbeta3-])

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.
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>
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
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.
Summary: Wallet tables not updated from netcenter -- caused a crash → Wallet tables not updated from netcenter
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.
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.
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.
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. :)
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.
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.
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().
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.
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
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
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
Closed: 25 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 → ---
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
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
I never have been able to reproduce this bug. Closing as works-for-me.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WORKSFORME
I as well, have never been able to reproduce this bug
Status: RESOLVED → VERIFIED
Assignee: morse → nobody
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.