251328 - PRE block doesn't render properly with firefox. Bad CSS?

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Maurizio Nadai]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1

The above mentioned URL is not rendered properly on Firefox, while with IE it
works fine.

I thought it might be a Firefox related issue, then I noticed that in the CSS
file (http://www.bugzilla.org/css/screen.css) the style of the PRE tag has a
"background" statement that points to a transparent.png image. 

I think that path is wrong (you use relative paths for these things, so for this
page it might need to be one level deeper when browsing pages at a lower levels,
but that will break all other pages... oh well!)

I dumped the page with HtTrack and changes the path in the CSS file, and it
seems to work fine.


Reproducible: Always
Steps to Reproduce:
1. browse the URL with Firefox (mine is v.0.9.1).

Actual Results:  
The central part, where there's the text tagged with <pre>, has a funky
background. It reproduces the left dark-gray bar and, sometimes, the top banner.
It also slows down the browser.


Expected Results:  
Just a clean page, with a transparent bg where the main text appears.


Maybe this page shows a problem with Firefox too, but I believe there's a
problem with the CSS anyway, that's why I filed it here.

I haven't filed anything for Firefox. I leave it to whoever fixes this.

Same problem happens to the other "Release notes" page, at
http://www.bugzilla.org/releases/2.18rc1/release-notes.html

Comment 1

[Dave Miller [:justdave]]

Hmm, looks fine in my Firefox (0.9 on Mac OS X)

Mike?

Comment 2

[Maurizio Nadai]

Dave, may I add that

1. the path to transparent.png in screen.css is "../img/", and there's no such 
directory under "/releases/", which is the parent ("..") of the document's 
directory ("/releases/2.16.6/").

2. therefore the way the page use the toplevel (and only one) CSS file is 
broken, i.e. it's a bugzilla.org issue

Now, whether Firefox on W2K should act like that under these circumstances, 
it's a Firefox-related issue, IMO.

I suggest somebody looks into the CSS and how relative links are used across 
the site. Then a different bug might be filed for Firefox on W2K...

Ciao

Comment 3

[Dave Miller [:justdave]]

http://www.w3.org/TR/CSS21/syndata.html#uri

"Relative URIs (as defined in [RFC1808]) are resolved to full URIs using a base
URI. RFC 1808, section 3, defines the normative algorithm for this process. For
CSS style sheets, the base URI is that of the style sheet, not that of the
source document."

Comment 4

[Michael Morgan [:morgamic]]

As Daved stated, links to images in the CSS file are made from the scope of the
CSS file, not the referencing document.  

For example, if I am in /releases/ or /status/ and I am linking to screen.css,
url(../img/foo.png) is made from /css/, not any other directory.  This is a
normal method and is in use at mozilla.org for more than 1 image (and we use it
on bugzilla.org for many other images -- like the ant background).

I cannot seem to reproduce this problem either.

Comment 5

[Dave Miller [:justdave]]

Guess that makes it an issue with the version of Firefox he's using...

Comment 6

[Bill Mason]

WFM 20040709 PC/Win2000 Trunk

Comment 7

[R.K.Aa.]

Pages look the same in Mozilla (trunk) and Opera. Changing product to Firefox.

Comment 8

[Thomas Malcolm]

The <pre> blocks (code examples) in the MSDN library are pretty much unreadable:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemsecurityprincipalwindowsidentityclassimpersonatetopic2.asp

Its not respecting the newlines/CRLFs/whatevers in the HTML source.
I only began to notice this in 0.9.x, if memory serves correctly, this wasn't a
problem in 0.8 and previous.

Comment 9

[Zac Shepherd]

I am seeing problems with the pre tag causing text to overrun an adjacent table
- example: http://perl.about.com/od/perlarrays/l/aa061599c.htm

I am tempted to open a new bug, but they seem like the two issues could be
related.  

Not sure if pre tag is deprecated or not.

I am using Firefox 1.0 on win 2k

Comment 10

[Francisco Moraes]

This URL renders pretty bad on Firefox while it is perfect on IE:
http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q270139

The problem is mainly in the <pre> blocks.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

Let's not confuse this bug with bug 255117. This bug as is works for me, so I'm
resolving it as such. Reopen if you still see problems in recent nightly builds.