Firefox 3.6.xx and 9.0.xx lose CSS formating if "Aggregate and compress CSS files" is not selected [#1412832]

Basically, out of the box, a standard 7.10 install does not have this selected. So when you first set up a Drupal site, it will not format and flow correctly at all and looks like garbage on at least some versions of Firefox. True, most people will turn this one on, but it is not on by default, and that leaves us open to having someone deploy a site where this has not been checked (pun intended -- ha!) and the reputation of the entire community could suffer as a result.

It may be a bug with Firefox itself. However, I think we should at least have the installation script turn this on by default. While that is not a true and complete solution, it could enormously reduce our exposure to ridicule. I keep running into this, and in a way, I am doing this bug report to remind myself of this "gotcha!" that is out there (and maybe should not be...)

I am suspecting it may relate in some way to what was going on here:

http://drupal.org/node/986558

At least that bug (while fixed) tickled my head well enough for me to remember seeing this behavior before and how to fix it.

There are going to be a lot of Fledgling Developers (like myself) that are going to get frustrated with this. Even if this is due to misbehavior on the part of the browser, I think we should try to go beyond just a work around (that itself could be an even more subtle pitfall that someone could be trapped by) and see if we can't make this work regardless of whether CSS compression is enabled or not.

Comments

Comment #1

aspilicious CreditAttribution: aspilicious commented 22 January 2012 at 12:25

Are you sure clearing the caches doesn't fix the issue?

Comment #2

Clearbrook CreditAttribution: Clearbrook commented 22 January 2012 at 16:05

It does not. If you have it turned on (at least on a 7.10 base setup with no additional modules turned on and using the default theme) and turn it off, the Firefox Browser that I am using right now (9.0.1) will loose all format information from CSS. Try clearing the cache, (even twice) and it will not help. Turn "Aggregate and compress CSS files" back on again (even without clearing the cache) and Voila! it works just fine. You can toggle it back and forth, alternately breaking it and fixing it, without ever clearing the cache.

I have come across this before. See:

http://drupal.org/node/1025558

I use both I.E. 8.0.7601.17514 and Firefox 9.0.1 as my baseline in Windows 7. I do have Virtualbox setups with Windows XP and various other versions of the browsers that I eventually validate everything on. But I don't go there if it breaks on the baseline. If you have I.E. and Firefox running, you can point both to the same site. Have I.E. version logged in as Admin and point at the overlay for this. Switch this on and off, and watch what happens to the Firefox Version.

This might be theme related. I had only checked this against Bartik 7.10 (which is the default theme out of the box) but just checked against Garland 7.10 and and Stark 7.10, but the results are the same. If this is a theme problem, then it is exactly the same problem in all three basic themes.

;'{)

Comment #3

droplet CreditAttribution: droplet commented 22 January 2012 at 19:09

Does it load CSS in HEADER ? try CTRL + SHIFT + K, check if the browser get downloaded the CSS files.

I'm using FF9.0.1 Win as primary development browser and never hit this problem

Comment #4

Clearbrook CreditAttribution: Clearbrook commented 22 January 2012 at 19:49

An "ah, HA!" belongs here.

My ISP has for some reason decided that they know what they are doing when CSS files are served up as type "text/html" instead of "text/css", so in this case, the problem is not with Firefox, but with my ISP. (and I.E., which does not enforce the requirement that CSS files need to be of type "text/css") I could not get them to correct this, so I had to set up .htaccess to cause CSS files to be parsed by php, and put php code to explicitly load MIME type of "text/css" instead of letting Apache send the header it thought was right based upon the configuration they had set up.

My assumption, (and I am pretty sure about this without even looking) is that when the CSS files are Aggregated, the new files that are sent have got code that explicitly sets the MIME type of the files to "text/css" as they are written, because if I turn Aggregation back on, this is what I get:

I am wondering if the files themselves are set up that way and that adding a php script that recursively goes through the directory tree and finding all the files ending with .css and rewriting them explicitly as MIME type "text/css" will do the trick? Hm... I think I will write that code and see if it works. This may be a bug that is specific to only some ISPs and will not occur in all Drupal installations, and if that is the case, this is an esoteric bug indeed! LOL!

If this code works (or if it does not) I'll report back with the code. If it does work, I'd suggest putting it in the install script and the cron script. And if it does work, do I get credit for a bug-fix in core Drupal? (Wow, now that is a concept that blows my mind!)

Well, here goes nothing, as they say...

;'{P~~~

BTW, thanks for suggesting looking at the loading screen. This may also point to a solution that takes care of the problems I have had with my other sites CSS with this ISP!

Comment #5

Clearbrook CreditAttribution: Clearbrook commented 22 January 2012 at 20:01

So this may not be a bug with Drupal per se, but if this works, it is code that is more robust to fix problems caused by ISPs that configure their Servers in unusual ways...

;'{P~~~

Comment #6

droplet CreditAttribution: droplet commented 22 January 2012 at 20:46

Category:

bug

» support

contact your server provider or add "AddType text/css .css" into htacess. Try to google the solution :)

Comment #7

webchick

she/they

English

Vancouver 🇨🇦

CreditAttribution: webchick commented 22 January 2012 at 21:01

Title:

Firefox 3.6.xx and 9.0.xx loose CSS formating if "Aggregate and compress CSS files" is not selected

» Firefox 3.6.xx and 9.0.xx lose CSS formating if "Aggregate and compress CSS files" is not selected

Sorry. Spelling errors bug me. ;)

Comment #8

Clearbrook CreditAttribution: Clearbrook commented 22 January 2012 at 21:34

Category:

support

» bug

droplet,

Yeah, I think I tried the "AddType text/css .css" solution before. Maybe I did not do it correctly, (my syntax could have been off or something) so it is worth another try. As for getting my ISP to change their settings, I tried and they acted dumb as rocks when I explained the problem. If the .htaccess solution works, it should probably be added to Drupal for people who have ISPs that fail to see this as a problem.

webchick,

Sigh. That is what I get for relying upon spell check highlighting not picking up that I was not trying to let the CSS code go free... (good catch, though)

;'{)

Comment #9

Clearbrook CreditAttribution: Clearbrook commented 23 January 2012 at 03:22

Ugh!!!

Ok, so this is not going to be easy to fix. The primary error is obviously with my ISP who for some reason or another has (or at least seems to have, since I cannot see it) edited their mime.types file to specify that .css files are to be treated as MIME type of text/html instead of the proper text/css per IANA. I am also thinking that they have configured Apache with AllowOverride of something other than all or none but not allowing FileInfo. (see: http://httpd.apache.org/docs/2.0/mod/core.html ) I previously had the following in my .htaccess file looking like this on another site hosted with the same ISP and on the same server:

# handler for php exec of css files (to force header right)
 <FilesMatch "\.(css|style)$">
  SetHandler application/x-httpd-php
 </FilesMatch>
# Why?  Because the following is not enough to get this mis-configured server to serve up css as MIME type of text/css
AddType text/css .css

However, I commented it out, and the css still worked.

The reason is probably because I was lucky in the way I chose my naming convention when I did my code to force the header to indicate a MIME type of text/css. I used a file named "imageflow.php.css" which was only the following code:

<?php

// Use this file in your HTML in place of the .CSS file if it works offline but not online.
// It will send the correct MIME type so that IE will execute the script correctly.
// In strict mode, *only* IE 7 does not care what MIME type is used and all compliant
// browsers correctly ignore css files if they are sent with say, a file type of 
// text/html because some administrator is too dense to understand how badly they screw
// things up when the do stupid stuff like this!

header('Content-type: text/css');
include('imageflow.css');

?>

In order to fix this, I tried using Addtype even putting an explicit RemoveType directive before it. That did not work. In Bartik, I tried using ForceType on the css Directory (which should have gotten me enough to see some formatting at least) and that did not work either. Which leads me to infer how my ISP has their Apache server setup in this respect. The fact that my .php.css file worked is probably due to something quite obscure that I ran across.

If you look here: http://httpd.apache.org/docs/2.0/mod/mod_mime.html you will notice under the section labeled "Files with Multiple Extensions" near the top, you will notice a couple of sentences.

Care should be taken when a file with multiple extensions gets associated with both a MIME-type and a handler. This will usually result in the request being by the module associated with the handler.

I think I accidentally utilized this feature.

So, maybe this should be more of a support request. I am not of the opinion that Drupal is bugged, but that various ISPs configuration of their servers obviously is. If you search Google with apache addtype not working you will see a lot of frustrated people noticing this very problem. Why they can't understand that serving up the correct MIME type can be so critical, I fail to understand, but it is plainly obvious that this is a widespread problem.

My stop gap solution would still be the same: Have the install script turn on Aggregate and compress CSS files by default.

The complete solution is beyond my abilities, I am afraid. I would approach it by renaming all the .css files to .php.css (double extension) and putting code in the beginning that forced the MIME type to be correct, and could do other things (such as specifying compression, etc.) as well. The problem with that solution is that it would require some rework of the Aggregation Routines, since they would have to parse out and discard that php code, or the whole thing would start barfing error messages and quitting, and in such a case the cure would be worse than the disease.

Oh well, it was fun, and I learned a few more things, which perversely, was part of my intention and motivation all along. (heh)

;'{P~~~

Comment #10

Clearbrook CreditAttribution: Clearbrook commented 23 January 2012 at 03:27

Category:

bug

» support

Comment #11

Clearbrook CreditAttribution: Clearbrook commented 23 January 2012 at 03:32

Oh, and webchick, that grammatical error from apache.org is not my fault! They should have wrote: ...the request being handled by the module associated...

;'{)

Comment #12

Clearbrook CreditAttribution: Clearbrook commented 23 January 2012 at 16:29

Having a little more time to think about this, I think I can propose a solution. If all css and javascript files were paired with another .php.css and .php.js file that forced the correct MIME type, as I did above (with somewhat less snarky comments, obviously -- to retain our professional image) then the aggregation routines would not have to be modified so highly. I think they would have to look and see if the .css files and .js files were .php.css and .php.js files instead, and if they were, aggregate the associated plain .css and .js files instead. Themes and modules that did not adhere to this might not adhere to this corrective behavior, (which is to provide a good solution to many ISPs shortcomings) but then they could have bug reports (which might truly be thought of as bug reports) to bring them into compliance with this new standard.

What do you think? Phase one: Have the installation script set css aggregation on by default on the next stable release. Phase two: Have the more comprehensive fix put in place and people made aware of the new protocols, inserting it into a stable release at some point convenient in the future. Phase three: Seek out modules and themes that do not comply with the .php.css, .css and .php.js, .js pairing and help them make the simple changes needed to comply with the new standard.

Just throwing this out there. And trying to conceive of as clean and painless a solution to this very real, if only somewhat widespread, problem...

;'{P~~~

Comment #13

23 January 2012 at 16:29

Version:

7.10

» 7.x-dev

Core issues are now filed against the dev versions where changes will be made. Document the specific release you are using in your issue comment. More information about choosing a version.