All users were logged out of Bugzilla on October 13th, 2018

Mozilla diverts to a netscape ad page without reason



18 years ago
4 years ago


(Reporter: Dinh-Tuan.Pham, Assigned: bc)






18 years ago
When I search an item from my library site (entering the above ULL then
clicking on "catalogues"), I would get a list of search results containing the
articles which have been found. Then by clicking on this article I would get a
web page of dercription of it. With mozilla, I get instead an ad page of Netscape !

This is _not_ a problem with my library site: I have tested with three other
browsers: Netscape version 4, Konqueror and Opera, all work as expected, except
for mozilla of all versions up to this verion 0.9

THis means that I cannot use mozilla, as I would be denied the service of my

1) Mozilla doesn't provide anny error message nor saying why it divert to
Netscape, but launching mozilla on an xterm window, I see this

Error loading URL
: 2152398878
Document keyword:cgi-bin loaded successfully

2) Netscape automatically enable the side bar (which I have diabled), which
contains a windows of "Search results" containing strange things completely
unrelated with the item I am seraching in my library site.

3) I am not sure if the site

can be assessed from outside the local domain for you to reproduce the bug.

Comment 1

18 years ago
Works for me if I enter the search term "rapport" even so the resulting URL is
ridiculously long. What search terms did you use?

Comment 2

18 years ago
In response to

> Works for me if I enter the search term "rapport" even so the resulting URL is
> ridiculously long. What search terms did you use?

I just try the search term "rapport". Yes, I get a list of "rapport",
but then I select the first item, that is

1: (Congres) Bases de donnees : nouvelles perspectives : rapport du groupe BD3

and click on "affiche les notices" and that is when mozilla diverts me to
the ad page of netscape, instead of displaying the "notice" as expected.

Did you continue like me ?

The same thing happens for any search terms, Try for ex, Einstein.
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 3

18 years ago
Ok, like this I can confirm the bug.

If you want that someone has a look at it, you shouldn't change
the bug status to Resolved/Fixed. Everyone thinks now
that this bug doesn't occur anymore. :) "Reopen" should do the trick.
(Can't do it for you, I haven't any privileges).

You should also change the component to something else, it's certainly not
chatzilla. I'd say it's "networking: HTTP", but I'm not sure. (Just been
watching and commenting on the incoming bugs.)

Thanks for reporting bugs.
I think the problem is that search result URLs are like this:

          <a href="http:/cgi-bin/...">

This is an uncommon syntax. The normal syntax is:

          <a href="/cgi-bin/...">

Although RFC 1808 seems to allow that strange notation (generic-RL).

This "Generic-RLs" seems to work Ok on MSIE and Nav 4.x but not in Mozilla

Comment 5

18 years ago
As suggested by
I reopen this bug (I was unaware that it has been marked fixed) and change
the components to "networking: HTTP" (chatzilla was there by hcance because I
havn't enter anything -- not knowing what it should be)

When I sent this, it was collide with the explanation of
Daniel Mario Vega. This could be the case. But it woukld be difficult to ask
the webmaster of this site to change his setup, especially that it works with
most browsers
Component: chatzilla → Networking: HTTP
Resolution: FIXED → ---

Comment 6

18 years ago
reassigning to get it _out_ of rginda's box.
Assignee: rginda → neeti
QA Contact: mozilla → benc

Comment 7

18 years ago
per bug 84456 i'm giving this to evangelism [I was looking for Bug 32966 which 
i was going to dupe this against but...]
Assignee: neeti → bclary
Component: Networking: HTTP → Evangelism
Ever confirmed: true
QA Contact: benc → zach

Comment 8

18 years ago
wfm in mozilla 2001-06-06-19 0.9.1/win2k. does anyone have a linux box they can
test with? can't we mark this fixed?

Comment 9

18 years ago
Taking assignment since the site owner is the reporter.

Ok. I clicked on the Catalogues, searched for rapport, selected some of the
results and clicked the Afficher les notices button and was redirected to
netscape search due to the still existing invalid relative url http://cgi-bin/...

This *is* a problem with the library site. The fact that the other browsers do
something non-standard for the invalid relative url is one thing, but what is
the cost of changing the url to /cgi-bin/...?  

Sorry, we are trying to create a standards based browser and we don't try to
emulate bugs in other browsers.  Please fix the url and let us know so we can
check your site again or if you do not wish to fix the url let us know and we
will mark the bug wontfix.



Comment 10

18 years ago
Well, I will try to persuade the webmaster of this site to change his

But I would like to point out that I don't know of any brower other than mozilla which have this behaviour. You call this a bug of other browvers,
but their developpers could call this a "feature" of their browser.

At least you should put a message saying that the syntax is wrong instead of diverting to netscaoe (why netscape ?). This makes me clueless and surely so for an ordinary user. How can I argue that it is a bug of the site when it works for anyone using a brower other than mozilla ? As a matter of fact, I administer serval machines and have switched to mozilla from netsacpe 4.x, but I have to switch back because of an user complaint

Thank for looking into this problem and provining a very fast answers

Comment 11

18 years ago
How would you implement such a fallback that would allow users to code relative
URLS as absolute URLS? How could we determine what the user really intended so
that we could give them a syntax error?

Let's use a completely fictional oversimplified example to illustrate the
situation.  Suppose on my local network I have a machine called foo and a
machine named bar.

Then http://foo/ is a valid *absolute* URL for the first machine and http://bar/
is a valid *absolute* URL for the second machine.

Now suppose that on machine foo, there is a web directory named bar.

So, http://foo/bar/ refers to directory bar on machine foo. 

Now suppose we are writing a web page to be hosted on machine foo.  If we
supported the old, broken way of doing things then what does http://bar/ refer
to?  You might say, we could check to see if http://bar/ existed and if not then
look for a local directory. But what if machine bar is down?  Would we
automatically use the http://foo/bar/ directory on machine foo?  You might say
that we should check the local directory first, but then we would never be able
to reference the machine bar.

This is unnecessarily complicated. Any web admin should *know* the difference
beween absolute and relative URLS and we *shouldn't* be asked to support such
simple, trivial, web admin 101 mistakes.

How many other 'common' mistakes should we code work arounds into the browser
for? Should web admins and authors never have to learn that they have been
making errors that have been covered up by idiosyncratic work arounds in earlier

Just because invalid practices work on old browsers, does not mean we are
condemned to support them forever. If you want the old way of doing things
supported, then get the standards bodies to incorporate it into the standards.

That odd syntax was part of a standard. See RFC1808 ( )

But then it was corrected in RFC 2396

In bug 22521 there is a long discussion about this problem. Also there is a lot
of bugs duped againts that bug. Perhaps the problem is more frequent than what
we originally thought.

Comment 13

18 years ago
Pham Dinh-Tuan, please excuse me while I remove my foot from my mouth...

Daniel, Thanks for the info. Looks like we may have to approach this in a more
organized fashion.

Changing priority to keep this bug visible and setting OS to all.
OS: Linux → All
Priority: -- → P2

Comment 14

18 years ago
I was discourage when I realize that this "bug" might be flagged WONTFIX.
I like mozilla but if this problem is not fixed either by you or the webmaster
of this site, I woiuld have to use another browser. Nevertheless I appreciate
very much your responsiveness. The webmaster of this site is like a ghost: I
have sent two e-mail *without any response* (may be there is no webmaster,
i.e. the page was created by some one who has left). Anyhow, I suspect that
the people in charge would react only if there are a lot of complaints, but
this is unlikely to happen when the major browsers like MSIE and Netscape still
support this syntaxe.

Comment 15

18 years ago
I have met the webmaster of this site and talk to him in person. He says that he has correct the systax (suppressing the http:/ before cgi-bin), but *the problem remains*

I also have myself looked at the source and search for the occurence of http and cgi-bin, The only place I find them now are

<form METHOD="get" ACTION="">

<a HREF="http:


Please be explicit: what is wrong with this source page ? I know nothing
about html and the webmaster doesn't seem to be very good at it either.

Comment 16

18 years ago
Dinh-Tuan, I looked at the page referenced above, and did not find any links
that did not work. gave me
an access denied message (I think), "Interdiction d'accès à ce service à partir
de la machine..."

I looked at the link to the Clips page and everything appeared ok there as well
including the relative links.

If you are still having problems, you can give us the exact links on specific
pages which do not work for you and we can take a look, but it appears that the
author is now correctly writing the links and if there are any that do not work
it is probably because he missed them during his earlier edits.

Comment 17

18 years ago
The problem with this site seems to be fixed. The webmaster has corrected
his syntax to conform with the new standard.

Comment 18

18 years ago
great! Dinh-Tuan, thanks a lot for working with us to get this resolved.
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 19

17 years ago
All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for
Component: Evangelism → US English
Product: Browser → Tech Evangelism
Version: other → unspecified

Comment 20

17 years ago
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.