I have an HTML page which references a number of stylesheets. Most of the stylesheets are "local" to the website. I have one stylesheet, however, that I reference from a CDN. It's the Font-Awesome css file. My reference is as follows:
<link type="text/css" rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.6.3/css/font-awesome.min.css" />
I reference the styles from this css file in several places across my application and an example reference is:
<span class="fa fa-pencil cursor-pointer margin-left-5" ng-click=\'openRoomEdit(dataItem)\'></span>
These references work fine everywhere except on Chromebooks. I have tested it on Edge, Firefox and Chrome on Windows and Safari and Chrome on Macs. It works on every single one of those of those examples. However, on Chromebooks, it can't find the styles from that CSS and so the icons do not render.
On Chromebooks only, I'm getting a net::ERR_INSECURE_RESPONSE in the Network panel when it tries to load the CSS file from the CDN. I'm referencing the file using https, from an app that runs as https with a valid SSL cert.
When I install the Font-Awesome files local to the application and reference it that way, everything works fine. I would prefer to be able to reference it via a CDN, but since many of my clients use Chromebooks, I need to figure out why this doesn't work.
To be sure the issue does not rely in the specific SSL BootstrapCDN is using, you should try using this one instead has a first step.
https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.7.0/css/font-awesome.css
cdnjs and BoostrapCDN are both using SHA-256, but BootstrapCDN is using a Symantec that has been generated on October 2016 and it makes me think of this bug in Chrome 53 where Symantec certificates were automatically rejected. I dunno if you can control the versions of Chrome your clients and you are using, but it might be a lead if they are not up-to-date.
Also what kind of certificate are you using for you own website? Is it trusted? It not, you can use LetsEncrypt to create one trusted by most CAs. There has been issues in the past about self-signed certificates and Chrome you can find at tickets #516808 and #516808.
If nothing helps, you may want to do a NetLog dump so we have more info about your issue.
Related
I am making a website using PHP. While completing it I tested it on Firefox only. Today when I tried to test it on other browsers (Opera, Chrome & Internet Explorer) I found some problems in my CSS. When I made changes to my CSS file, none of these browsers except Firefox is showing changes made in the CSS file.
<link rel="stylesheet" type="text/css" href="style.css" media="screen">
So far what I have tried after Googling for a long time is
Cleared Cache memory of browser
Put "?v='+1 everytime'" at end of style.css
Refresh the webpage using 'ctrl+f5', 'ctrl+r' etc.
Any help ? Thanks in advance....
This is intended behaviour by most browsers. Whenever you try to load a page, if any resources are already present in browsers' cache, they will be loaded from there.
You have two options:
disable browser cache for your preferred browser (some browsers allow you to disable cache for specific domains)
make your HTML always refresh the resource, by appending a non-repeating parameter to the requested resource file name. I personally use: ?v=1482939287 (where 1482939287 is the timestamp). This will make the browser always refresh the resource, as it will ask for a version that's not existing in browser cache.
Example: <link rel="stylesheet" type="text/css" href="/css/style.css?v=1482939287">
Update: You can flush the cache for a webpage by opening Dev Console (Ctrl+Shift +I), right-click-ing on refresh page arrow (while Dev Console is open) and selecting Empty Cache and Hard Reload. That is emptying the cache.
You can also disable it, as suggested above, by opening Dev Console, going to Network tab and checking "Disable Cache" checkbox right under it. Please note that cache is only disabled while your developer console is open.
There are several solutions for this. I will list you some of my options below.
Unique identifiers to files though parameters
Adding a parameter behind the file as a kind of a version number may help.
In php you can use time() to get the current timestamp or unique() to get a unique string.
Cache settings server side
You can also find some .htaccess settings for caching specific file types on the server side. For performance reasons you should do this for production, too.
Browser Dev Tools
Another way is to open your Browser Dev Tools (mostly F12) while developing. Most browsers like Chrome and FF provides a cacheless enviroment when your Browser Dev Tools are open. As a example in chrome you can disable caching explicit.
My suggestion
Or even better use Task Runner to accomplish this. The keyword to search for is 'cache bust'. As example you can run gulp for concat, versioning, and let it connect the right css files you want to. This is specially suggested for development phase.
regards
Gkiokan
I am developing a website that uses the Google font Open Sans like so:
<link href='https://fonts.googleapis.com/css?family=Open+Sans:400,300,300italic,400italic,600,600italic,700italic,800italic,800,700' rel='stylesheet' type='text/css'>
Normally, I use Chrome when working with my website, but today I decided to see how it looks in IE 11 (11.0.10240.16431) on Windows 10. Unfortunately, Open Sans isn't being loaded and rendered properly. I see lots of these errors in the Developer Tools console:
CSS3111: #font-face encountered unknown error.
PRmiXeptR36kaC0GEAetxjqR_3kx9_hJXbbyU8S6IN0.woff
Thinking that was strange--I had previously developed a site that loaded Google Fonts just fine in IE 10--I headed on over to https://www.google.com/fonts. More CSS3111 errors, with every custom font being displayed in serif instead:
Is Google Fonts simply broken for IE 11? The fonts do load correctly in Edge, Chrome, Firefox, etc. I am at a loss for how to proceed to get these fonts to work in IE.
UPDATE 1
Setting the emulated document mode to 8 in IE 11 causes the fonts to render correctly. IE 9+ still exhibited the same issues, however. Is this some kind of incorrect user agent string processing by Google, perhaps?
UPDATE 2
I went to FontSquirrel and downloaded Open Sans in all its formats. I also imported the CSS provided in the ZIP. Unfortunately, IE and now Firefox continue to report that the font can't be used. Firefox says downloadable font: not usable by platform.
UPDATE 3
I've confirmed that IE's Font download setting is set to Enabled for all security zones.
For me, this issue was caused by a Windows 10 feature called Untrusted Font Blocking. My office network had this turned on in our group policy settings.
Using this feature, you can turn on a global setting that stops users from loading untrusted fonts that are processed by the Graphics Device Interface (GDI). Untrusted fonts are any fonts that are installed outside the %windir%/Fonts directory. https://support.microsoft.com/en-us/kb/3053676
To disable Untrusted Font Blocking using Group Policy:
Open Group Policy Management Editor
Under Local Computer Policy, expand Computer Configuration, expand Administrative Templates, expand System, and then click Mitigation Options.
In the Untrusted Font Blocking setting select Do not block untrusted fonts
To disable Untrusted Font Blocking using Registry Editor:
Open Registry Editor (regedit.exe) and go to the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Kernel\
If the MitigationOptions key is not there, right-click and add a new QWORD (64-bit) Value, naming it as MitigationOptions.
To turn this feature off. Type 2000000000000.
IMPORTANT: A computer restart is required for the changes to take effect
As weird as it sounds, the solution is to turn on the Windows firewall. With the firewall switched off, you cannot even add TTF fonts to the system, and this is the same problem as with #font-face. I've found that solution here: https://superuser.com/questions/957907/unable-to-install-fonts-on-windows-10
Don't worry about font blocking. Turn your fonts into base64 and include through CSS. This way you push the fonts through the browser code and the font files are not downloaded in the usual fashion. This is also a DISA STIG issue to disable downloadable fonts. The solution can be seen at this post and also copied here:
You just need to Base64 the font and include it in a CSS file. Make sure to remove your call to the downloadable WOFF file once you include the call to the new FontAwesomeB64.css
Use https://www.base64encode.org/ to encode the WOFF Font-Awesome font file.
Edit the the resulting file and add these lines. When you get to the src:url line, make sure to run that right into the base64 information you received (don't use the greater than and less than signs I show here.) At the end of that base64 information add the single quote, parentheses, a semi-colon, and curly brace to finish:
#font-face {
font-weight: 400;
font-style: normal;
font-family: 'FontAwesome';
src:url(data:application/x-font-woff;base64,<insert base64 code here>);}
You now have a base64 CSS file of the Font-Awesome font that bypasses all font download denial settings in browsers.
I've found that this works with all fonts, a little heavier on the download but worth the guarantee of functionality.
I have this exact problem on many Windows 10 / IE 11 machines (ie web fonts do not work and give CSS3111 errors in the debug console). In all cases the firewall was already on (and managed by group policy).
I found that disabling the firewall in the registry
HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\EnableFirewall = 0
followed by a reboot, then setting it back to 1 and rebooting again fixes the problem.
The other thing that always fixes the problem is to unselect "Internet Explorer" in the Windows Features, reboot, then reselect "Internet Explorer" and reboot again.
My guess is that this is some type of internal windows firewall bug and both of the above actions trigger the firewall service to clean up some type of internal corruption.
In Windows 10 there are three levels for font blocking:
IE security settings for downloading fonts (user part)
Option "untrusted font blocking" (Computer level)
Option" Enable front providers" (Computer level)
You have to enable all, to get it working.
I'm having a problem using Vaadin (in Eclipse) and its associated styling engine Valo, and the TouchKit package. I mention all of these because I'm not sure which, if any, is causing the problem. The name of my custom theme (which imports Valo) is simply "touchkit".
I have the project running on a Tomcat server on localhost and accessible in my browser. I wanted to tweak some of the CSS so I edited the appropriate file WebContent/VAADIN/themes/touchkit/touchkit.scss. After editing this file, I recompile the theme and see the appropriate changes in the generated file styles.css. Then I go to load up the application in my browser, and things get weird.
I can load the page and, using Chrome's developer tools, see that the page requests styles.css for download, as expected. It gets a 200 OK response from the server, but when I view styles.css, it contains just a single \n. This is also true in Safari. Even using cURL to download styles.css yields the same result. In the Eclipse editor, and when I inspect it in the terminal, styles.css is ~12,000 lines long. Why can't my browser or cURL get that data?
I can view similar project demos on Vaadin's own site and the stylesheet (which should be almost identical to mine) is loaded correctly. Also, other Vaadin projects on my localhost server have their stylesheets loaded correctly (though they do not use Valo). Compiling the theme in Eclipse yields no errors. Because the issue presents itself across a variety of graphical and non-graphical clients, I'm starting to think the issue is with Tomcat. But I can get to the directory from which Tomcat serves files and styles.css is correct in that folder too. There's no apparent reason that Tomcat would be serving a blank file.
You may have guessed from the description, but I'm working on a Mac. Any help is appreciated!
PS Mods - I also asked this question over at Superuser since it wasn't 100% a programming question. However, I'm new at Superuser and couldn't create tags for Vaadin or Valo, so I'm asking here where there might be a better chance of getting an answer.
Hard to say, since your are doing everything fine. My best bet would be the tomcat implementation you are using, maybe there's something weird there. Try upgrading to latest if it's not or to a previous version.
FYI I'm using Tomcat 7.0.55.
PS: your attempts are in run/debug from eclipse or have you made a .war form the project and deployed it with the Tomcat-Manager?
Regards
add below to your gwt.xml, and touchkit is not valo aware see https://vaadin.com/forum/#!/thread/8264224/8264223
<set-configuration-property
name='touchkit.manifestlinker.additionalCacheRoot'
value='src/main/webapp/VAADIN/themes/MyTheme:../../../VAADIN/themes/MyTheme' />
Here is picture in chrome:
I just woder what does user stylesheet mean here. The case is that I am 100% sure that these classes does not exists in my stylesheets (it was before). I thought It comes from cache but it remains even after cache is cleared. Any ideas? Thanks.
First of all, read this definition of what a user style sheet is. It is an extra stylesheet to help you (the user) browse the web. Hence if you prefer certain CSS settings over what the web page designer intended, you can overrule those settings with your own.
This user stylesheet that you found, may therefore just be a local CSS file on your pc.
Therefore we need to know: where did you find that .CSS file?
If the same file is in this location:
PC: C:UsersYourUsernameAppDataLocalGoogleChromeUser DataDefaultUser StyleSheetsCustom.css
MAC: ~/Library/Application Support/Google/Chrome/Default/User StyleSheets/Custom.css
Then the answer is:
The file above is, as it sounds, a CSS file that you can modify and add your own custom styles to, to change the look and feel of your Google Chrome Web Inspector.
Which means that with that specific stylesheet you can change the look of your Google Chrome Web Inspector.
So it has nothing to do with the website you are inspecting, only with how your web inspector looks (it is built with HTML, CSS and JavaScript).
You can read about it here. (Google Chrome version 33 does not feature custom stylesheets)
It could also very well be the case that Google Chrome implements some other user stylesheet that is stored somewhere else on your pc (but I wouldn't know where exactly).
Note that the inspector also shows user agent stylesheets which is the default stylesheet that your browser implements. You can read about those in this question: What is user agent stylesheet
It is possible that the http server itself has cached the previous version of the file and is serving it.
Reload and check the headers in the Network tab, so you can get the full picture. Or if you are using development environment, you can restart the server - just to be sure.
I'm developing an ASP.Net app that is using html5shiv and ssl. For some reason I am getting mixed content errors in IE7 using html5shiv. If I remove html5shiv the errors go away. I'm also using update panels and master pages if that matters. Any ideas?
Edit: After further testing it appears to be a combination between html5shiv and a stylesheet. If either are excluded, no mixed content error.
<script type="text/javascript" src="../js/html5shiv.js"></script>
<link rel="stylesheet" href="../styles/global.css" />
Solution: I had a data uri on a header style. Removing the uri solved the problem.
Are you using the externally hosted html5shiv (on a CDN)? If so, download the file and host it yourself on the same server.
If you're using https, you need to make sure that all files are served via https. If you have any http downloads on the page, you'll get mixed content warnings.
It sounds like your html5shiv file may be being served via http, and this is causing the problem.
If you're downloading it from a third party site, check whether that site allows https downloads. If not, you may need to serve it yourself.
This ended up being an issue with a css style with a data URI. Apparently IE7 recognizes this as mixed content. The modernizer was dynamically loading a header tag which is the element the offending css style was applied to.