From Bugzilla Helper: User-Agent: Mozilla/4.72 [en] (WinNT; U) BuildID: 2000042708 I do a daily pull_all and build and after doing that, my HTTP Notify listeners registration always fails. If I continue to let the browser come up, close it, and then restart it then the registration succeeds. What appears to be happening during the first startup is that nsNetModRegEntry.cpp attempts to get the nsEventQueueService. The service is not started yet, so an instance is created/started, and returned to nsNetModRegEntry successfully. nsNetModRegEntry then attempts to retrieve the event queue for the current thread. However, no event queue for the current thread has been created yet so the call fails and the overall listener registration fails. For all subsequent startups of the browser, nsAppShellService::Initialize function is invoked before my HTTP Notify listener registration is invoked. nsAppShellService creates an event queue for the current thread. So when my HTTP Notify listener registration is invoked, nsNetModRegEntry successfully gets the event queue for the current thread and then completes the listener registration successfully. The service that I am creating that performs the HTTP Notify listener registration is registered with NS_HTTP_STARTUP_CATEGORY to initialize when the HTTP protocol starts. What I'm seeing is that there is a call to CheckForNewChrome in main1 of nsAppRunner.cpp just before the nsAppShellService is created (which starts the nsEventQueueService and creates an event queue for the current thread). The call to CheckForNewChrome is causing the HTTP protocol to initialize which causes my service to initialize and then encounter the error because the nsAppShellService hasn't gotten a chance to create the event queue. As a developer I can work around this by restarting the browser. But an end user will be missing function the very first time he installs and starts the browser. Reproducible: Always Steps to Reproduce: 1. Delete all entries in bin and bin\components 2. Build 3. Use the existing Init fuction within nsCookieHTTPNotify.cpp and set a break point at the call to RegisterModule 4. Step through and you'll find the error. 5. Continue to allow the browser to initialize and come up. 6. Restart and see that the error does not occur the next time.
Sorry for the spam. New QA Contact for Browser General. Thanks for your help Joseph (good luck with the new job) and welcome aboard Doron Rosenberg
QA Contact: jelwell → doronr
pav, I know you've been working with the event queue lately - any idea what's happening here?
setting to NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
updating component and setting default owner.
Assignee: asa → gagan
Component: Browser-General → Networking
QA Contact: doronr → tever
this is a very old bug. Can you confirm if you are still seeing this (since a lot has changed since the time this was filed)? thx.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
Pulled and rebuilt yesterday and the bug is still there.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Just re-checked this on the latest build and the problem is no longer present.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → FIXED
marking verified per reporters comments
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.