View Issue Details

IDProjectCategoryView StatusLast Update
0014219mantisbtinstallationpublic2012-06-22 07:48
ReporterRichardLynch Assigned Toatrol  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionno change required 
OSLinux Server / OS X clientOS VersionRHEL 5.5 / SnowL 
Product Version1.2.3 
Summary0014219: CSS not being applied
Description

The mantis logo and all other artwork are missing.

Upon inspection, none of the CSS selectors appear to match their corresponding HTML elements.

The mantis logo is clearly visible by mousing over the SRC in Firebug.

The default.css is in the HEAD, and can be loaded and viewed.

Additional Information

Please see attached images.

I just don't see how the connection between the CSS file, the LINK tag in the head, and the HTML can be broken.

All the pieces are confirmed in the right place.

TagsNo tags attached.
Attached Files
mantis_missing_logo.png (150,236 bytes)   
mantis_missing_logo.png (150,236 bytes)   
mantis_missing_css.png (264,734 bytes)   
mantis_missing_css.png (264,734 bytes)   
mantis_css_there.png (230,674 bytes)   
mantis_css_there.png (230,674 bytes)   
content_type_css.txt (1,872 bytes)   
http://mantis_curriculum.dev.deltakedu.corp/login_page.php

GET /login_page.php HTTP/1.1
Host: mantis_curriculum.dev.deltakedu.corp
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20100101 Firefox/12.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: PHPSESSID=jib75f0dt73og5imr3gpemo5n3
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.1 200 OK
Date: Wed, 09 May 2012 16:34:44 GMT
Server: Apache/2.2.3 (Red Hat)
X-Powered-By: PHP/5.3.3
Cache-Control: no-store, no-cache, must-revalidate
Last-Modified: Wed, 09 May 2012 16:34:44 GMT
X-Content-Type-Options: nosniff
Expires: Wed, 09 May 2012 16:34:44 GMT
X-Frame-Options: DENY
x-content-security-policy: allow 'self'; options inline-script eval-script; frame-ancestors 'none'
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Length: 1427
Connection: close
Content-Type: text/html; charset=utf-8
----------------------------------------------------------
http://mantis_curriculum.dev.deltakedu.corp/css/default.css

GET /css/default.css HTTP/1.1
Host: mantis_curriculum.dev.deltakedu.corp
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20100101 Firefox/12.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: PHPSESSID=jib75f0dt73og5imr3gpemo5n3
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.1 200 OK
Date: Wed, 09 May 2012 16:35:18 GMT
Server: Apache/2.2.3 (Red Hat)
Last-Modified: Wed, 02 May 2012 20:43:22 GMT
Etag: "7e6e06-1964-bcf06e80"
Accept-Ranges: bytes
Content-Length: 6500
Connection: close
Content-Type: text/css
----------------------------------------------------------
content_type_css.txt (1,872 bytes)   

Relationships

related to 0014300 closedatrol Styles (CSS) are not shown 

Activities

RichardLynch

RichardLynch

2012-05-08 12:35

reporter   ~0031774

When I say the images are "missing" or the css isn't "there", I mean visually.

Physically the screenshots show them in place.

atrol

atrol

2012-05-08 14:47

developer   ~0031777

Are you able to reproduce the issue with latest stable version? (1.2.10 atm)

RichardLynch

RichardLynch

2012-05-09 11:01

reporter   ~0031784

I haven't tried in 1.2.10 yet, but it appears to only affect firefox 9 and firefox 12.

I tried to upgrade to get firebug to work, and then went to Chrome to demo the issue and saw the lovely logo...

If you tested with non-Firefox, please try again.

I will try to upgrade, and poke the firefox people...

RichardLynch

RichardLynch

2012-05-09 11:11

reporter   ~0031785

Bah.

Firefox is going Nazi on us. If the server doesn't send text/css, it's not css, even from a LINK type="text/css" tag.

https://bugzilla.mozilla.org/show_bug.cgi?id=146630

Close it, and I'll just stop using Firefox.

Firebug stopped working anyway.

RichardLynch

RichardLynch

2012-05-09 11:17

reporter   ~0031786

Hang on...

If your app is over-riding the server mime-type.info or whatever it is, and you have header("Content-type: text/html"); for your CSS files, then I guess it is your buglet...

You can probably find that out faster than I can...

RichardLynch

RichardLynch

2012-05-09 12:11

reporter   ~0031787

You/We are sending Content-type: text/css

HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Wed, 09 May 2012 16:09:17 GMT
Server: Apache/2.2.3 (Red Hat)
Last-Modified: Wed, 02 May 2012 20:43:22 GMT
ETag: "7e6e06-1964-bcf06e80"
Accept-Ranges: bytes
Content-Length: 6500
Connection: close
Content-Type: text/css
Length: 6500 (6.3K) [text/css]
Saving to: `default.css'

100%[===============================================================================================================================================================>] 6,500 --.-K/s in 0.008s

2012-05-09 11:09:17 (806 KB/s) - `default.css' saved [6500/6500]

RichardLynch

RichardLynch

2012-05-09 12:37

reporter   ~0031788

Aha!

Surfing directly to the CSS file give Content-type: text/css

Going through the application somehow changes that to text/html.

Firefox will fail for that reason.

atrol

atrol

2012-05-11 11:55

developer   ~0031818

Can this be closed as "no change required"?

RichardLynch

RichardLynch

2012-05-12 13:04

reporter   ~0031820

I don't think so.

There is still an issue here, even if all my research hasn't identified the exact root cause.

atrol

atrol

2012-05-12 14:10

developer   ~0031821

Are you able to reproduce the issue with a new installation (no custom functions, no plugins) of MantisBT version 1.2.10 on the same server?

RichardLynch

RichardLynch

2012-05-22 16:34

reporter   ~0031882

The latest version 1.2.10 on the same server reproduces the issue.

I also put it on my own public webhost and all is fine.

The original came from the client's webhost, and all is fine.

So far, we have eliminated:
0011534
0011917
https://bugzilla.mozilla.org/show_bug.cgi?id=146630
version 1.2.10 versus 1.2.3
DNS versus /etc/hosts name service (we use /etc/hosts internally)
NATO Summit

As you can tell from those last two, and especially that last one, we're running out of ideas here. :-)

Since it's only on an Intranet server, if you (or any Mantis Dev) would be willing, I could do a Cimco web/tele conference, if that would help.

You could view the issue, drive ssh sessions, tail the logs, add debugging code etc.

I'm generally available Mon through Fri 10 am to 4 pm US Central (GMT -5).
Tue/Thu 10:30 am is a regular meeting I can't miss, however.

Hopefully this suggestion isn't too presumptive...

RichardLynch

RichardLynch

2012-06-04 17:08

reporter   ~0032003

I'm not sure this is the same as 0014300...
We're not even seeing the mantis logo.

Just for fun, I used LiveHTTPHeaders, a Firefox extension, to check the mime-types of the CSS etc.

Firefox isn't even requesting the resources.

Here is the COMPLETE request/response for the login_page.php:

http://mantis_curriculum.dev.deltakedu.corp/login_page.php

GET /login_page.php HTTP/1.1
Host: mantis_curriculum.dev.deltakedu.corp
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20100101 Firefox/12.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: PHPSESSID=fddib1mogeeef8ujebbqu28i97
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.1 200 OK
Date: Mon, 04 Jun 2012 20:59:59 GMT
Server: Apache/2.2.3 (Red Hat)
X-Powered-By: PHP/5.3.3
Cache-Control: no-store, no-cache, must-revalidate
Last-Modified: Mon, 04 Jun 2012 20:59:59 GMT
X-Content-Type-Options: nosniff
Expires: Mon, 04 Jun 2012 20:59:59 GMT
X-Frame-Options: DENY
x-content-security-policy: allow 'self'; options inline-script eval-script; frame-ancestors 'none'
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Length: 1425
Connection: close
Content-Type: text/html; charset=utf-8

That's it.

No request for the logo that's there.
No request for the CSS that's there.
It's like Firefox rejected even asking for the content...
Why is the question...

atrol

atrol

2012-06-04 17:16

developer   ~0032004

You should try also a fresh install of FF without any extension.

RichardLynch

RichardLynch

2012-06-11 16:44

reporter   ~0032071

Last edited: 2012-06-11 17:25

Still beating my head against the wall on this one.

Firefox with all four (4) of my extensions disabled and re-booting Firefox in "Safe Mode" for good measure had no effect.

The same issue happens to all firefox users here, and it's unlikely we share that many extensions.

atrol

atrol

2012-06-11 17:39

developer   ~0032072

Just a guess: FF has problems with subdomains that are longer than a certain length or with more than two "." in it.

atrol

atrol

2012-06-11 17:56

developer   ~0032073

Last edited: 2012-06-11 17:58

Furthermore the underscore "_" seems not to be a "good" character for subdomain names.

Google for: problem underscore domain
and you will see what I mean

I tried on one of my test installations which is a shared hosted package.
The provider didn't even allow to create a subdomain with a "_" in it.

grangeway

grangeway

2012-06-11 19:32

reporter   ~0032074

The underscore is not a legal character for use in hostnames. It's use in other DNS entries is fine.

As defined in original RFC's hostnames may contain:

Alphanumeric (a-z and 0-9): Both uppercase and lowercase letters are acceptable, and the hostname is case insensitive.
Hyphen ( - ): - used to be not first/last character but this ma have changed in a newer RFC iirc
Period ( . ): only to delimit fields 

So this isn't a mantis issue.

Paul

atrol

atrol

2012-06-12 02:47

developer   ~0032075

For the records:

Both RFC's do allow "_" in URL and URI
http://www.ietf.org/rfc/rfc2396.txt
http://www.ietf.org/rfc/rfc1738.txt

This one does not allow for domain names
http://www.ietf.org/rfc/rfc1035.txt

grangeway

grangeway

2012-06-12 08:12

reporter   ~0032079

almost - rfc2396 doesn't for the hostname component:

Hostnames take the form described in Section 3 of [RFC1034] and
Section 2.1 of [RFC1123]: a sequence of domain labels separated by
".", each domain label starting and ending with an alphanumeric
character and possibly also containing "-" characters.

RichardLynch

RichardLynch

2012-06-12 14:15

reporter   ~0032084

Razza Frazza Fuzzum $*#&$

The _ in the domain name was it.

Hopefully anybody with similar troubles will find this.

The multiple dots almost have to be okay...

www.company.co.uk

I don't think RFCs/Firefox will make that non-kosher anytime soon.

RichardLynch

RichardLynch

2012-06-12 14:17

reporter   ~0032085

Might I add that if Firefox isn't going to accept "_" in the domain name, then it should be consistent and not server up ANYTHING for that domain name.

Serving up the HTML but not images and CSS is just daft, in my humble opinion.

RichardLynch

RichardLynch

2012-06-12 14:59

reporter   ~0032086

Should anybody find this, and want to weigh in on the Firefox inconsistency issue:

https://bugzilla.mozilla.org/show_bug.cgi?id=764080