115484 - Some sourceforge image tags broken in mozilla.

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[David Finch]

Once you're in SSL mode (logged in) at sourceforge.net, many of the image urls
are preceded with an "https:", with no //. This works fine in Internet Explorer,
but not in Mozilla. Example image tag from a sourceforge page:
<IMG src="https:/themes/forged/images/tleft1.png" border=0 width=17 height=17>

I've also posted a bug report at sourceforge.net for this. It appears that those
urls beginning with a protocol name but no // should be treated as relative
urls, but using the specified protocol. I'm not sure if this type of url is
standard or not, but I've never seen it used anywhere else.

I'm using build 2001112009

Comment 1

[Olivier Cahagne]

This is a dupe of bug 32966 but should be moved to Tech Evangelism.

Comment 2

[timeless]

reporter: can you note the sourceforge bug report url here?

Comment 3

[eberry]

The bug report link for SourceForge is here:
  http://sourceforge.net/docman/display_doc.php?docid=7632&group_id=1
Or click "Contact Support" in the left margin at:
  http://sourceforge.net/
They prefer you have a SourceForge account when reporting bugs, but it isn't 
required.

Comment 4

[David Finch]

The img urls at sourceforge are handled correctly in Netscape 4.6, making this a
backward incompatibility.

Fix it for the sake of quirks mode..

Comment 5

[timeless]

sorry. we refuse to do that. the feature being used by sourceforge has been 
deprecated for many years. probably before most of us started using the web.

I asked for the specific bug url because i'd like to stick it into our url 
field to aid the evangelism team.

Comment 6

[Olivier Cahagne]

It's been fixed by SF team, see
http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1#sfwebsite:

(2001-12-17 15:24:00)   The SourceForge.net team has corrected an issue related
to display of icon images on the SourceForge.net site; all images now display
correctly. Those projects making use of HTML export of project summary
information should manually run their collection script, to ensure that icons
are displayed correctly in that section of their project web site; no action
need be taken if projects in question wish to wait for the next cron-based run
of their collection script.

I verified with build 2001121803 on Win2k and there's no problem now.
Marking FIXED.
Please reopen if you still see a problem.

I didn't find the bug number on SF site, there was no URL or bug # posted here.