Closed Bug 11766 Opened 25 years ago Closed 25 years ago

Registering Wallet hangs URL Fetch at start-up

Categories

(Toolkit :: Form Manager, defect, P3)

x86
Windows 95
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: dp, Unassigned)

Details

There is a problem, that dp diagnosed, that causes URL loading to not work the
first time you install. It is related to the Wallet downloading tables at start-
up. dp is all over it, and this should be fixed for M9.
Severity: normal → critical
Target Milestone: M9
To reproduce, touch components/wallet*.dll and rerun. Steve this could be
because of the event loop stuff you checked in. I think the best fix is to
eliminate the event loop and use a checked in wallet mapping file for now.

We can talk about the async way of doing this.

Marking it M9. Uping priority.
Actually paulmac filed this bug from my browser. That is why this seems like I
filed the bug.
Adding myself to cc.
can we just going to disable this?
Status: NEW → ASSIGNED
I'm working on a fix.
Although I am in the process of implementing a fix for this, I discovered that I
am unable to reproduce the problem.  I just pulled and built a fresh tree and
deleted my moz registry.  The first time I executed, I went through the profile
manager and arrived at the mozilla.org page.  The wallet files got downloaded.
I was able to visit other URL's as well.  Then I exited the browser, touched the
dll as per the description above, and re-entered.  Same results -- I had no
problem loading URL's.

To make the test even more interesting, I then disconnected my network
connection, touched the dll's and started again.  Of course the files didn't get
downloaded this time and the mozilla.org page didn't load.  But the browser
continued to function perfectly and I was able to load url's (from my local disk
of course).

There was one slight problem that I did encounter as a result of the
asynchronous loop that is downloading the wallet files.  Namely, if you have no
network connection, then this loop never terminates even when you exit the
browser.  So you have to kill the browser off manually.  I had observed this
when Andreas originally gave me the code to do the downloading and mentioned it
to him.  Neither of us considered this to be a serious problem and figured we
could correct it post M9.

Paul and dp, could you please retest this and let me know if you are still
seeing this failure.  I am not seeing the failure indicated.
I reproduced it was on a release build. You are probably building debug.

Maybe you will see the problem, if you download the bits that we put out from
mozilla.org
The bits from mozilla.org don't even start up (crash in profile manager) or
maybe I wasn't installing it correctly because I haven't pulled bits in a long
time.  So as an alternate, I built my own optimized build.  Much better --
profile manager didn't crash.  And again I do not see the problem described in
this report.  So for both optimized and debug builds, this works for me.  I am
using a tree from around midnight last night.
I just heard from jpatel that this works for him as well.
I pulled the Aug 12 bits off mozilla.org and I cannot reproduce the bug.
Previously I pulled the bits using install.exe and there I can reproduce the
bug.

I dont know what bits the installer is pulling. It seems to pull from
ftp://sweetlou

Could this be a Netscape build only thing ?
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
I did not see it this morning when I launched 8/13 build for the first time.
could be an intermittent problem that both paul and I have seen.

... the kind that a large tester sample size helps to uncover.
marking works for me.  re-open if we get it to repro state.
This might be a duplicat of 11716.
Updating QA Contact from paulmac to sairuh/
QA Contact: paulmac → sairuh
verif.
Status: RESOLVED → VERIFIED
Assignee: morse → nobody
Product: Core → Toolkit
QA Contact: bugzilla → form.manager
Target Milestone: M9 → ---
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.