Closed Bug 221324 Opened 21 years ago Closed 19 years ago

Get "http is not a registered protocol" error on startup; no HTTP loading

Categories

(SeaMonkey :: General, defect)

x86
Linux
defect
Not set
major

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: eliasen, Unassigned)

Details

(Keywords: regression)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030925
Build Identifier: Mozilla/5.0 Linux CVS pull 20031005

After updating CVS on 2003-10-05, I get "http is not a registered protocol"
after building on Red Hat Linux 9.0.  This is the first time I've seen this
error.  I tried lots of things to clean the distribution, including make clean,
clobber, cleandist, depend, and none of these worked.  After none of these
worked, I deleted the entire mozilla source and dist directories, and pulled a
full clean version of Mozilla from CVS.  Same problem.

Reproducible: Always

Steps to Reproduce:
1. make -f client.mk  on Red Hat Linux
2. Start mozilla


Actual Results:  
Get "http is not a registered protocol" and no loading via HTTP is possible.
Attempted to rebuild twice with different tests.  No luck.  But I do at least
have a better version number than I put in the bug report.  file: and ftp: URLs
do work, by the way.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031005
hm... can you load about:buildconfig and paste its content here?
  Here are the buildconfig arguments.  I've been building on Linux for several
months and never had this problem before (I also didn't change any arguments,
compilers, etc between builds.)  Just for fun, I also tried removing all of the
optional arguments (pthreads, crypto, LDAP) below.  No luck.

--------------------------

about:buildconfig

Build platform
target
i686-pc-linux-gnu

Build tools
Compiler 	Version 	Compiler flags
gcc 	gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) 	-Wall -W -Wno-unused
-Wpointer-arith -Wcast-align -Wno-long-long -pedantic -pthread -pipe
c++ 	gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) 	-fno-rtti
-fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-long-long -pedantic
-fshort-wchar -pthread -pipe -I/usr/X11R6/include

Configure arguments
--with-pthreads --enable-crypto --enable-ldap-experimental 
I deleted my entire personal profile which fixed the problem (but was painful.)

Later, rebuilding my profile, I found that the bug manifests itself when I use
the common flash-blocking code in userContent.css that I've used for a long
time.  (Listed below; I will also create as attachment.)

   Did this break for a reason?  Or did it just break?  The selective Flash
blocking below allows you to "click to play" any Flash instead of having it
autoplay.

/* Doesn't work for <embed> tags, which are less common than <object> tags - bug
190970 */
object[classid$=":D27CDB6E-AE6D-11cf-96B8-444553540000"],
object[codebase*="swflash.cab"]
{ -moz-binding: url("http://futureboy.homeip.net/temp/flash.xml#obj"); }
This file goes in your profile's chrome directory.
Alan, what's the last build that works for you?  If we can narrow the regression
date down, that would be helpful.  My bets are on it breaking in the afternoon
on October 1.

I just tried putting that CSS in my userContent.css and it worked fine, btw.  Do
stock mozilla.org nightlies work for you?
I downloaded Linux nightly build 2003101505 and it *does* work for me,
Flash-blocking included.  Very odd.

Unfortunately, I don't know the last build that worked for me.  I did a CVS pull
on 2003-10-04 and it broke starting with that.  I hadn't pulled for several
days.  I've tried new CVS pulls (including deleting my whole CVS tree) every day
since and none have worked.

Switching that userContent.css file in and out break and fix the browser
reliably.  By the way, that's the only thing in that file.

What do you suspect changed on October 1st?  Anything that I can test?  If I
need to pull whole CVS trees from certain dates, I can do that.
The fix for bug 113173 would make us create URI objects at sheet parse time.  If
the sheet is parsed before the HTTP protocol handler has been registered, that
could lead to the error you observe.

The sheet is parsed when we observe a profile-after-change notification, though;
I'd expect the HTTP protocol handler to be registered long before then.

I'm not sure whether you can easily back out bug 113173 and follow-ups to test;
it may be simpler to just pull by date from before that checkin and then pull by
date for a time after it...
WFM in Seamonkey and Firebird nightlies on WinXP.  I even tried using your URL
for flash.xml.  I assume your home page doesn't contain any Flash.

Possibly related: bug 221973, "Image loaded from user style sheet opened in
default browser (result: infinite browser windows opened)".
Keywords: regression
Product: Browser → Seamonkey
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
No response for the auto-resoling comment, so resolving manually. Feel free to reopen this bug if you can reproduce it with current SeaMonkey builds.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: