Closed
Bug 11340
Opened 25 years ago
Closed 25 years ago
[PP] Wallet contents page is complete blank
Categories
(Toolkit :: Form Manager, defect, P3)
Tracking
()
VERIFIED
FIXED
People
(Reporter: kevinyen, Unassigned)
Details
Latest build 080508. Enter wallet password to View Wallet contents. The wallet contents page is completely blank (white). Just the window frame around it. thx, kevin
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Comment 1•25 years ago
|
||
This is an unfortunate side-effect of 10456. When we download the wallet files for netcenter (i.e., people.netscape.com for now), necko was hanging (that was bug 10456) so Andreas gave us a temporary work-around that enables the download to work (on unix and windows at least). But apparently that work-around doesn't work when we are also trying to bring up the wallet viewer at the same time. I was able to determine this from the debugger by breaking when this white screen was being displayed. At this time I discovered that the fetch-from-netcenter routine was looping. As further proof that this is the case (and also as a work-around), force the tables to be downloaded prior to bringing up the viewer. You can do this by submiting a form and requesting that the data be saved. Then go to the wallet viewer and this time it will come up fine (because it won't be competing with the fetch-from-netcenter). So I'm marking this as a dup of 10456. *** This bug has been marked as a duplicate of 10456 ***
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Summary: Wallet contents page is complete blank → [PP] Wallet contents page is complete blank
Comment 2•25 years ago
|
||
Here's an interesting tidbit. This bug is platform dependent. We of course can't test it on the mac at all (because the patch for bug 10456 specifically does not work on a mac). But it works fine on linux. It fails only on win32. So I'm marking this as [PP]. Although it is caused by the patch put in for 10456, that patch may become permanent. In that case we can't consider this as a dup of 10456 so I'm removing the dup indicator.
Updated•25 years ago
|
Resolution: DUPLICATE → ---
Updated•25 years ago
|
Status: REOPENED → ASSIGNED
Updated•25 years ago
|
Target Milestone: M9
Comment 3•25 years ago
|
||
Here's more information on what is going on. The wallet editor is a dialog that is invoked from nsBrowserAppCore.cpp. The editor itself is an html file (soon to be xul) which has javascript that calls into the wallet code in order to get the values in the wallet. The wallet code checks to see if the netcenter files have already been downloaded and, if not, it will download them. Let's consider the case in which the netcenter files were previously downloaded. Such a download would have occured if the user did a previous quickfill. At that time, when the data is actually received back from netcenter, the notification gets to the wallet code via the following stacktrace (Input Consumer is in the wallet code): InputConsumer::OnStartRequest(InputConsumer * const 0x0a1b6ed0, nsIChannel * 0x0a1b6e60, nsISupports * 0x00000000) line 152 nsHTTPResponseListener::FinishedResponseHeaders() line 619 + 37 bytes nsHTTPResponseListener::OnDataAvailable(nsHTTPResponseListener * const 0x0a1b65d0, nsIChannel * 0x0a1b6990, nsISupports * 0x0a1b6e60, nsIInputStream * 0x0a1b66c0, unsigned int 0, unsigned int 375) line 151 + 8 bytes nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x0a1b6660) line 350 nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x0a1b6664) line 149 + 12 bytes PL_HandleEvent(PLEvent * 0x0a1b6664) line 509 + 10 bytes ... Note that nsStreamListenerEvent is in the trace. OK, now consider the bad case -- i.e., netcenter files have not yet been fetched. Now when the wallet-editor comes up, the stacktrace is quite large but an abbreviated version is as follows: wallet_FetchFromNetCenter(char * 0x09b03a7c, char * 0x09b03a6c) line 1466 ... bunch of javacript levels ... nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x0ab28a94, nsIChannel * 0x0ab28090, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000) line 1031 nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x0ab54620) line 274 nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x0ab54624) line 149 + 12 bytes PL_HandleEvent(PLEvent * 0x0ab54624) line 509 + 10 bytes ... Note that the nsStreamListenerEvent is already on the stack from the wallet editor. But in order to get the notification when netcenter data arrives, we would have to again go through through the nsStreamListenerEvent (as shown in the top stack trace). This will block and so wallet will never get notified when the data comes back from netcenter. Therefore we stay in the while loop (of the temporary 10456 patch) forever. The saving grace is that we are going change all this so that we request the data from netcenter completely asynchronously at the start of the browser session. This will completely remove this deadlock. I'll be able to close out this bug report once that change occurs. Shooting for M9 if at all possible.
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 4•25 years ago
|
||
Wallet tables are now donwloaded when browser starts up. This completely avoids the problem described here.
Comment 5•25 years ago
|
||
So with all the talk of improving start-up performance, why are we downloading the tables at start-up? Is this a temporary workaround or permanent move? Sorry to pipe in so late in the conversation. Are we going to do this even for people who have wallet turned off? What happens if they start-up off-line? Final question, is this netcenter download enabled for just the commercial build, or the mozilla builds, also? These questions are as much for kevin as they are for steve.
Comment 6•25 years ago
|
||
Downloading is done in background so it should not at all affect startup performance. It is a permanent move. Currently we are doing this even if they have wallet turned off. We might optimize this in the future. If the user starts up off-line there is no problem since this is a background activity. It simply never completes but the browser continues to function normally. The netcenter download occurs on all builds -- commercial as well as mozilla.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 7•25 years ago
|
||
verified
Updated•16 years ago
|
Assignee: morse → nobody
Product: Core → Toolkit
QA Contact: paulmac → form.manager
Target Milestone: M9 → ---
Version: Trunk → unspecified
You need to log in
before you can comment on or make changes to this bug.
Description
•