I'm using Bootstrap glyphicons. They are working nicely, but with Chrome browser, the glyphicons blink when the page loads
For example:
Open this link on Bootstrap:
http://getbootstrap.com/components/#glyphicons-glyphs
Once loaded, Press F5 or refresh.
You will see the glyphicons blink.
How can I fix it so they don't blink?
Here's a screenshot:
Note: This only happens in Chrome, not FF or IE.
Generally, this is a problem with having a flash of unstyled content (FOUC).
Specifically, this is what Paul Irish calls a flash of unstyled text (FOUT):
In Firefox, basically the text is in a default webfont until the custom font is ready
Webkit takes a very different approach, and very intentionally. They believe it’s better to keep the text invisible until the font is ready. This way, there is no moment where the text flashes into its newly upgraded self
In other words, this issue isn't so easily overcome.
You can attempt to minimize the impact by:
Using gzip to shrink the file so it downloads quicker
Using caching so the client can use an existing copy rather than grabbing a new one.
The heavy handed approach would be to wait to display the page to the user until everything was rendered, but I would strongly recommend against this. User are very impatient for initial load times but are considerably more forgiving when it comes to rendering additional content.
The glyphicons blink/flicker on page reloads, but the bigger problem for me (I'm using Bootstrap 3) is that the page flickers as elements resize around the glyphicons. Adding this to my CSS stopped the resizing for me:
.glyphicon {
width: 14px;
height: 14px;
}
Thanks to my source: https://www.garysieling.com/blog/preventing-icon-flicker-using-glyphicons
I had exactly the same problem but solved it by adding .woff and .woff2 as new MIME-types font/x-woff in IIS.
This stopped the glyph-icons from blinking immediately as Chrome now caches the font-file correctly.
To see if this may apply to you, open the debug-console in Chrome (F12) on the site it blinks and you will find an error related to the glyph-font-files where the browser interprets them as the wrong MIME type.
Related
First, I've seen the duplicates
What is #shadow-root, and why does it put display none on my font awesome classes?
and
HTML / CSS - DIV Element hidden when it shouldn't be?
however both of these suggest the issue is with adblock and I have totally disabled adblock.
I am more concerned with where the #shadow-root is coming from, since I certainly did not put it there.
I have read that there is an option in chrome to disable it (and interestingly enough I have it disabled...), but this means that anyone using my website will need to do the same, and I'd rather just do away with it entirely as it provides zero usefulness in my application.
I have also googled and read many of articles about the shadow dom and none of them give any insight on why it would appear seemingly for no reason.
From what I have seen in inspector/view page source, the entire contents of my app are being rendered into this shadow dom and thereby not receiving any of my styles.
I am using rails, react, redux, react-redux, react-router
Chrome developer tool screen
Page Source screen
Notice that the source has nothing in the div that react should be rendering to.
Additional info:
displays unstyled page on chrome in normal and incognito
does not work at all in safari
A lot of chrome plugins automatically create this shadow root in your inspector. For example, ever since I downloaded Vimium, I've had a shadowroot div at the bottom of any page I've opened in chrome. It's nothing to worry about.
I was having the same issue and found that it was Adblock Plus that was adding #shadow-root. Thanks to the resources above I was able to assertain what the issue
For me it was also an Adblocker (uBlock) and it was actually hiding part of the webpage I was making which showed imported tweets. Turning the adblocker off for my site fixed it.
I don't know if it's an issue with a JS conflict, possibly a hidden jQuery/CSS thing, an invisible WebKit href inclusion, or just a bug in Chrome Version 43.0.2357.130 (64-bit).
The intent is to print the contents of a Flash drawing game--which was previously working on all browsers as well as Chrome--but this combination of Chrome and newer website code, clicking on print forces the Flash object to reload...which of course empties it so nothing will print.
Has anyone encountered this kind of behavior before? FWIW this site is using the Zurb Foundation system, along with jQuery and the http://ajax.googleapis.com/ajax/libs/swfobject/2.2/swfobject.js plugin.
(Because it's using Foundation, we have three instances of the SWF specified by size, though all other views are empty except the active one. I tested to see if this was a possible problem by removing all but 1 object on the page, but it made no difference to this behavior.)
To anyone who might by now be beating their head against a wall trying to understand this: I've discovered the specific issue that causes Chrome to crash Flash objects when it launches its print preview dialog:
Because enabling/disabling the .show-for-large-up and .show-for-medium-only tags (among others?) in Foundation.css were modifying the behavior, I created our own Modernizr-enabled screen size detection function to hide/show our divs without Foundation's tags. When I did that, printing on Chrome worked as it should.
Then, thinking I didn't need to invoke Modernizr/JS functionality when Foundation's own CSS file already accomplished this using #media queries, I deleted that function and simply added in display: block for our new custom hide/show tags. This caused Chrome to once again crash Flash objects.
So the issue is that Chrome's print preview dialog crashes Flash objects when CSS is using #media queries to determine the visibility of [at least] large- and medium-view content divs.
This points to a Chromium issue as printing Flash objects works fine on Safari, Firefox and Explorer. Specifically, the Chrome print preview dialog is not playing nice with Foundation's #media queries--and possibly the CSS of other third party providers.
I made a form on my WordPress site that listed a few options. When viewing the website in Chrome the text doesn't render correctly, however, it renders correctly when viewing the page via Internet Explorer.
Not too sure for the reasoning behind this. Does anybody have a clue?
Sometimes, the default font on your computer might have been overwritten expecially if your font is georgia, I most times have this problem as well, i think what you should do is find another machine running your version of chrome, preferably newly formatted without font installation and test the page. also check the encoding, [utf_8(http://en.wikipedia.org/wiki/Character_encodings_in_HTML) is the browser standard
This thread might show you how to change character encoding
Her is another resource that might help
When page of my application is loaded font in some html tags is default one and when you mouse over it, proper font immediately shows. I made a list of things that probably matters:
Position of element doesn't matter, it occurs on absolute and static.
Font of my choice if assigned to body tag so there is no way some stylesheets don't get loaded.
I load fonts via #import from fast.fonts.net. This line of code is almost on the top of my stylesheets, above is only reset.
I load my assets from s3, minified in one file.
It never occurs locally and the only browser that this bug was seen is Chrome.
It is rare bug, maybe 1% of all page refresh, so reproducing when you want to see it is difficult
Once I have seen this issue in bugsnag.com
App is heavy on front-end side
Do you have any ideas how I could fix it?
I discovered that injecting fonts via JS script tag and not css #import works best. After that client stopped reporting me this issue.
It's simple change and the reason why it works must be connected with some Chrome bug.
I'm currently finishing up testing a new Ruby on Rails app. Just recently, some of the pages do not seem to finish downloading in IE8. In FireFox, Chrome and Safari, everything works perfectly. The pages all validate successfully using the W3C validator.
When I view the page source in IE8, the page has been chopped off around 75% of the size it should be. IE8 claims the page is finished loading, and doesn't give any errors, but of course the page isn't rendering properly.
Has anyone seen this before? I'd really appreciate any help.
Have you tried to watch the http requests, using something like Http Analyzer or HttpWatch (like firebug for IE)? That might shed some light if there is a problem with a JS or CSS file not being found, or if the server is returning something other than a 200.
HttpWatch has a free version at http://www.httpwatch.com/download
IE8 Comes with a built in developer toolbar. Just press F12.
You should be able to diagnose most problems using it.
Also, open the page in Firefox with the Webdeveloper Toolbar addon and check if any javascript issues are arising. I find that sometimes you may only see the error in IE8 but you might only figure out what is wrong using Firefox. Give it a try!
There was a javascript call in the page that needed to be wrapped with:
document.observe("dom:loaded", function() { ... };
in order to work in IE. Apparently, it was disruptive enough to kill the entire page render. Thanks BenTheDesigner!
Since this is the first result on a Google search for IE8 not completing a page request, I thought I'd add on that I've seen the same symptoms caused by Sophos Anti Virus' Browser Helper Object which interferes with page requests and thus doesn't complete download requests every time.
Hitting F5 resolves the issue most of the time but a click to the next page can cause it to reappear. Other symptoms include odd page rendering of background images, incorrect repeating or no repeating being done at all despite a CSS declaration specifically telling a background to repeat. I spent a week debugging my CSS and XHTML only to eventually try disabling all the browser "Add-ons" and all of a sudden the issue went away.
I nailed it down to Sophos' BHO and now no rendering issues.