I just added Helmet to my Node/Express/EJS project and have been configuring my CSP to enable inline scripts, styles and some external sources. I have it working fine on my Windows laptop in Opera, Chrome & Edge and now I'm connecting on iOS Safari mobile and it appears that no styles are being applied. I am successfully getting Bootstrap (JS for sure, I think the CSS too although it's not 100% clear and I have no console on mobile) but my own stylesheets and scripts are not being loaded correctly.
Here's my code:
app.use(
helmet({
contentSecurityPolicy: {
directives: {
scriptSrc: ["'self'", "'unsafe-inline'", "'unsafe-eval'", "*.googleapis.com", "*.jsdelivr.net", "*.jquery.com"],
styleSrc: ["'self'", "'unsafe-inline'", "'unsafe-eval'", "*.googleapis.com", "*.jsdelivr.net", "*.jquery.com"],
baseUri: ["'self'"],
fontSrc: ["'self'", "https://fonts.gstatic.com"]
}
}
})
)
I also notice that whenever I visit a link on my site on iOS Safari it automatically forces HTTPS when I'm only using HTTP on a localhost server. I have a feeling that this may be the cause of the problem - my stylesheets are referenced as
<link rel="stylesheet" href="/style.css" />
I think Safari may be trying to find it at https://(laptop-private-ip):3000/style.css when it really should be searching http://(laptop-private-ip):3000/style.css. Is it possible that it's trying the HTTPS link which is why I can't retrieve my own styles, but can access Bootstrap etc?
And what should I do about it? Any help massively appreciated - I've wasted hours on this.
Issue fixed. I am not 100% confident which was the problem due to cache seemingly playing a part but I believe it was one of the following.
Upgrade-Insecure-Requests
HSTS
Related
I built this e-commerce site for a client using ReactJS and deploying via Netlify automatic github deploys. I'm getting very strange results in Firefox and Safari (Big Sur and before). This error appears in the Safari console:
Did not parse stylesheet at 'https://panthercityleather.com/src/index.css' because non CSS MIME types are not allowed in strict mode.
I'm assuming this is what is causing the layout issues? I tried to add type=text/css to all links and style tags but the command npm run build seems to remove these attributes from the tags.
I then locally ran npm run build (as opposed to letting Netlify automatically build), edited the build css to contain the correct MIME types, added autoprefixing to all of the css, and manually deployed this build folder to Netlify. Then I got a different error in regard to the index.css file:
Failed to load resource: the server responded with a status of 404 ()
I am completely lost at this point and would really appreciate any help. The layout issues only seem to arise on desktop Safari and Firefox and the issues are different in each browser. Here is an example from the home page:
Featured items on Chrome. Everything looks correct.
Featured items on Firefox. Note that the spacing between the headings and the images is too tight but the images are cropped correctly.
Featured items on Safari. Note how the images are now cropped wrong but the spacing is correct.
Maybe try adding type="text/css" to every link or style tag.
<link rel="stylesheet" href="css/style.css" type="text/css" />
<style type="text/css" > ... </style>
Turns out I had 2 issues:
I was linking index.css inside of index.html but with a React app this is not necessary. I simply need to import each css file into the react file that references it. This solved the error that I initially posted the question about but did not fix the weird styling behavior on other browsers.
My main issue was that my css was simply not supported on older browser versions. Specifically, aspect-ratio and gap did not have good support. I used the padding-top hack to provide a fallback for aspect-ratio. I simply removed all gap in my css because on Safari v14, the browser apparently supports gap but none of the styles were being applied. I've spent all day scouring the internet so I simply replaced all gap with something like this:
& > * + * {
margin-left: 1rem;
}
This applies a 1rem margin on all but the first element in a flex row. Change to margin-top for a flex column.
I am working on a static page that uses React, Gatsby, and styled-components.
When styling a page, my development workflow usually heavily involves Chrome DevTools, tweaking styles there until I have something that I like, and then implementing them in the code.
When using styled-components, however, all of the styles/rules that appear in DevTools for each rendered element are grey, italicized, and disabled. I can override them by adding styles in element.style {}, but that can be a pain, and it doesn't solve the root question which is: why are styles applied by styled-components disabled in DevTools?
Here's a screenshot of what I'm referring to.
It's because styled-components injects styles through the CSSOM API, which the Dev Tools in Chrome (and every other browser AFAIK) can't handle. See this ticket: https://bugs.chromium.org/p/chromium/issues/detail?id=387952
Note that this is only true when styled-components is in production mode, i.e. process.env.NODE_ENV is set to "production". As long as you aren't in production mode, styled-components should generate normal <style> tags, which you can interact with through the Dev Tools.
In v4.1.0 it's possible to provide SC_DISABLE_SPEEDY flag to disable styles injection with CSSOM insertRule.
More details
https://www.styled-components.com/releases#v4.1.0
https://github.com/styled-components/styled-components/pull/2185
I did a full quit of Chrome (Cmd + q), ran npm update, npm install, and did a full relaunch of the browser and localhost server. This fixed it for me.
At a guess, I'd say you might be affected by this bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=796629
If you close the dev tools and reopen them again, this might fix the issue temporarily.
we're stuck at a strange behavior in a clients project:
We have many SCSS files resulting in a compiled CSS file of 240000 characters in size.
I was able to develop in Safari without a problem.
Then a colleague started working on the same project using Chrome - he got a completely unstyled page. In Firefox he got the same problem. I tried it with Chrome and Firefox on the Mac too, and yep - they both won't display the page anymore.
"Anymore" because it worked fine. The only thing that changed is the SASS compilation workflow to use the Wordpress Plugin "WP-SCSS" instead of Grunt.
Our new compiled CSS seems to be bigger than the previous one. Maybe the underlying Foundation framework was customized, so that it did not include that many rules. Anyway: more rules should not end up in a broken stylesheet like in IE some years ago. Therefore Safari (both v9.1 and "Safari Technology Preview") render fine.
Yes, all browsers are up to date.
Yes, all caches are cleared.
Has anyone an idea, a hint, or a guess?
My site at http://arcrealtyco.com will not load in IE8. I have updated jQuery (1.9.1) and updated Modernizr (2.5.2) running on the site. It works fine in ie9 while using ie8 mode, but on ie8 it will not load. It appears the issue is with our CSS file.
Right now it is a 301k size file that has been concatenated from SCSS. I even tested a minified version that is 131k. nothing.
Any thoughts here?
Within the css file we have Bootstrap, Symbolset our global CSS and a few other things.
In your <footer>, you have a <br> inside of a <strong>. Try taking that <strong> away so it's just a <br> by itself. That made the crash go away for me. I used Windows 7 and the real Internet Explorer 8.
I have a css file that I only want to be visible to Firefox browsers. I thought I was super-smart coming up with
#-moz-document url-prefix() {
#import url("/a-large-css-file.css");
}
...only to find out that #import directives cannot be nested like that.
More details:
The file is heavy, so it's not an option for me to include its
content inline inside the "conditional" as I don't want for it to
affect total request size for other browsers
The file contains a font-face declaration with the font itself
base64-encoded. Why you ask? Firefox does not allow for fonts to be
downloaded from a different subdomain and that's how twe host static
content. There's a nice recap of the issue here and here
If you've looked through the links in the point above, you'd see a
suggestion to add an Access-Control-Allow-Origin http header -
unforunately this is not an option for me given our infrastructure
setup and deployment procedures.
Even more details:
Static content is hosted on a url similar to
resources.environmentN.domain.com while the pages' urls are similar to environmentN.domain.com where N is different across
the environments.
We're have Apache Tomcat running Liferay Portal.
At this stage I'm open to almost any workaround :)
Edit
I probably should have phrased this differently, but I must mention that I'm probably not open to javascript workarounds, the reason for that would be an unstyled content flash even after the resource is successfully cached locally - this would be the case with solutions proposed so far.
My apologies for the confusion!
You should really just bite the bullet and get the server side fixed, since http://dev.w3.org/csswg/css3-fonts/#same-origin-restriction requires the Firefox behavior and the other browsers will update to it at some point.
Detect browser with JavaScript then append stylesheet link if it's FireFox
$('head').append(' <link href="a-large-css-file.css.css" media="screen" rel="stylesheet" type="text/css" />');