View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0014219 | mantisbt | installation | public | 2012-05-08 12:31 | 2012-06-22 07:48 |
Reporter | RichardLynch | Assigned To | atrol | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | no change required | ||
OS | Linux Server / OS X client | OS Version | RHEL 5.5 / SnowL | ||
Product Version | 1.2.3 | ||||
Summary | 0014219: 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. | ||||
Tags | No tags attached. | ||||
Attached Files | 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 ---------------------------------------------------------- | ||||
When I say the images are "missing" or the css isn't "there", I mean visually. Physically the screenshots show them in place. |
|
Are you able to reproduce the issue with latest stable version? (1.2.10 atm) |
|
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... |
|
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. |
|
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... |
|
You/We are sending Content-type: text/css HTTP request sent, awaiting response... 100%[===============================================================================================================================================================>] 6,500 --.-K/s in 0.008s 2012-05-09 11:09:17 (806 KB/s) - `default.css' saved [6500/6500] |
|
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. |
|
Can this be closed as "no change required"? |
|
I don't think so. There is still an issue here, even if all my research hasn't identified the exact root cause. |
|
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? |
|
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: 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). Hopefully this suggestion isn't too presumptive... |
|
I'm not sure this is the same as 0014300... 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 HTTP/1.1 200 OK
|
|
You should try also a fresh install of FF without any extension. |
|
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. |
|
Just a guess: FF has problems with subdomains that are longer than a certain length or with more than two "." in it. |
|
Furthermore the underscore "_" seems not to be a "good" character for subdomain names. Google for: problem underscore domain I tried on one of my test installations which is a shared hosted package. |
|
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:
So this isn't a mantis issue. Paul |
|
For the records: Both RFC's do allow "_" in URL and URI This one does not allow for domain names |
|
almost - rfc2396 doesn't for the hostname component: Hostnames take the form described in Section 3 of [RFC1034] and |
|
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. |
|
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. |
|
Should anybody find this, and want to weigh in on the Firefox inconsistency issue: |
|