Closed Bug 11340 Opened 25 years ago Closed 25 years ago

[PP] Wallet contents page is complete blank

Categories

(Toolkit :: Form Manager, defect, P3)

x86
Windows 95
defect

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
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
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 ***
Status: RESOLVED → REOPENED
Summary: Wallet contents page is complete blank → [PP] Wallet contents page is complete blank
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.
Resolution: DUPLICATE → ---
Status: REOPENED → ASSIGNED
Target Milestone: M9
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Wallet tables are now donwloaded when browser starts up.  This completely avoids
the problem described here.
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.
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.
Status: RESOLVED → VERIFIED
verified
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.