Closed Bug 4863 Opened 26 years ago Closed 25 years ago

[PP] "Error Error 503 HTTP not enabled" on Mac Seamonkey launch

Categories

(Core Graveyard :: Tracking, defect, P3)

PowerPC
Mac System 8.5
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: elig, Assigned: warrensomebody)

References

Details

Attachments

(1 file)

* TITLE/SUMMARY "Error Error 503 HTTP not enabled" on Mac Seamonkey launch * STEPS TO REPRODUCE 0) <Some unknown voodoo happens here, maybe involving the Mozilla Registry and a previous build. In my case, it occured after launching the 4.8.99 PM build after a dirty registry from the last few days worth of builds.> 1) Launch Apprunner * RESULT - What happened New browser window appears with text resembling "Error Error 503 HTTP not enabled". Quitting and restarting Gecko results results in the "Welcome to the Gecko Browser" start page properly appearing; couldn't reproduce. (Note that this was the same error text we used to get upon opening a new Mac browser window, per bug #4587. Related?) Phillip notes, "This might be similar to the linux apprunner problem: the first time a new version of apprunner runs, it crashes in the registry creation/update. subsequent runs are ok. if it is, it is a known issue and your local developers are busily testing a fix for it." Couldn't conclusively prove or disprove Phillip's theory by upgrading from a few recent builds. * REGRESSION - Occurs On Mac OS Apprunner (4.8.99 PM optimized build) - Haven't Seen It Occur On Win32 Apprunner (4.9.99 AM optimized build [NT 4, Service Pack 3]) Linux Apprunner (4.9.99 AM optimized build) * CONFIGURATIONS TESTED - [Mac] Power Mac 8500/120 (233 Mhz 604e), 64 MB RAM (VM on; 1 MB of VM used), 1024x768 (Thousands of Colors), Mac OS 8.5.1 - [Win32] Vectra VL (233 Mhz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP3. - [Linux] Vectra VL (266 Mhz P2), 96 MB RAM.
QA Contact: 3853 → 1698
elig or claudius, the Mac Apr 09 build just came out. Any problems there?
I don't see this immediately taking place on the 4.9.99 AM build.
Target Milestone: M5
Set target milestone to M5. I don't see these problems. Can we get a real reproducible case here that we pass to the registry folks?
I've spent 20 minutes and couldn't distill a reproducible case. Claudius, any ideas based on your experience (hey, you're the one who found this first ;)?
Summary: "Error Error 503 HTTP not enabled" on Mac Seamonkey launch → [PP]"Error Error 503 HTTP not enabled" on Mac Seamonkey launch
the search for the reproducible testcase....well so far I haven't been able to come up with anything good. At this point I can only see this error once a day right I after I launch a fresh, new build. No, reinstalling a new copy of the same days build doesn't do it either(nor does blowing away the registry). So at this point just look out for it when installing an opt build for the first time. If anyone has any ideas..........
Summary: [PP]"Error Error 503 HTTP not enabled" on Mac Seamonkey launch → [PP] "Error Error 503 HTTP not enabled" on Mac Seamonkey launch
[This took place again on Mac OS during the upgrade from the 4.13.99 M4 build to the 4.16.99 AM daily build.] I note that there isn't a menu bar.
I also note that (clicking outside of the browser window, covering up the text and then clicking back on it to force a redraw) the noted text is drawn in three separate chunks: "Error" (pause) "Error 503" (pause) "HTTP not enabled".
Also, I think the only way we're going to get a reproducible test case is by backing up the Mozilla registry prior to doing the daily upgrade, and using the backed up copy as the bug trigger. I'm going to start doing this. Claudius, would you be open to trying this, too? (especially if you haven't already downloaded today's buids)
[Haven't seen a problem in the April 20th or 22nd Mac builds so far.]
Target Milestone: M5 → M6
Changed milestone to M6.
This occured in upgrading to today's build, from (most recently) the 4.22.99 build. Unfortunately, I was totally spacing after the weekend and forgot to backup the registry first. Claudius is wisely backing up his registry before upgrading to today's build and will see if it happens to him.
Since Claudius is out to lunch, I'll take the liberty of posting that he did in fact dutifully preserve his registry file, and has now created a reproducible case. Hail Claudius to the Maximus! ;)
Component: Apprunner → other
Target Milestone: M6
dp, it looks like they finally got a reproducible case. Is this for you?
Assignee: don → dp
Assignee: dp → warren
Status: NEW → ASSIGNED
Depends on: 7232
Target Milestone: M9
Deferring until necko is available.
No longer depends on: 7232
Blocks: 7232
Using the 8.4.99 Mac OS build and Claudius's preserved registry, I can no longer reproduce this bug. (Nobody has been reported it for several months.) However, this may be because I connect to Claudius's server. Could you possibly give it a quick look, Claudius? Thanks!
I swapped out my registry with the attachment and I was no longer able to reproduce the problem. Eli, do with this bug what you will, you have all my blessings as it works for me.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Since neither aka Claudius or I can reproduce this bug, marking as Verified Fixed.
Verified. (ignore the 'aka' in last comment.)
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: