I am building a website that uses Google Visualization API, and it works fine (even in IE), except for production server. Basically:
In all browsers not made by microsoft it works;
In IE8, 9 on the dev server (localhost:8000) it works;
In production, it fails saying 'Your browser does not support charts', which is not true.
No https involved, js is taken from Google, no browser or js errors at all. HTML from dev and production server is the same, I actually checked with the diff tool.
Any ideas on why can this happen or how do I fix this? Example URL: http://publishedin.com/websites/profile/penpen.in/ (graphs are in the left column).
I have similar charts running in IE 9 without a problem. Other people have noticed this problem when there is some kind of code collusion on the page.
So, try creating a page that only runs the charts, nothing else. If it works, there is some code on the page interfering with the chart creation.
I got your charts to run in IE 8 & 9:
http://www.jensbits.com/demos/charts.php
I have found IE to be particularly intolerant of code that confuses it.
Related
I need your help my website is not functioning properly on firefox browser but in edge, chrome and opera and safari it works only firefox is not functioning properly
Firefox Browser
Google Chrome Browser
I would recommend setting up all your projects in Xampp or something similar first before testing it. If you are going to upload to a server you need to replicate the environment locally before you decide whether it is going to work or not. It seems complicated but it is quite simple, you can find out more here. https://www.apachefriends.org/
That said, check your urls, they are not the same for your two different screens, the one is referencing an anchor tag.
I have a very strange problem with webfonts and firefox.
I made a website with DIN webfont as a font-face, and it is displayed perfectly well in all the browsers, when the website is hosted on my personal server:
http://daviddarx.com/stuffs/work/pozzo/04/
But, since we transfered the website on final servers, the webfont isn't displayed anymore in firefox (mac version), while it still is ok in other browsers:
http://pozzo.ch/
Do you have any idea what the problem could be?
I can't figure it out, cause it's working fine locally and on my server. Also do I think that the problem may come from the final server configurations, or urls, or anything else.
But I haven't any knowledges in these technical fields.
It seems this line src:url("../fonts/din_regular.eot?#iefix") on your font-face makes trouble on firefox.
try to remove the "#", so write this line like this: src:url("../fonts/din_regular.eot?iefix")
I'm working on a corporate intranet and we have recently redesigned it using all sorts of CSS3 goodness as specified by a design agency. Our corporate standard browser is (still) IE8 so in order to make the CSS3 work I employed CSS3 PIE (http://css3pie.com/) which recreates the CSS functionality using VML via a .htc file - and it works great. However I've noticed that the http_referer value for pages viewed in IE8 is being returned as the location for pie.htc instead of the actual referring page and it was working just fine before the redesign. Firefox is tolerated as an alternative browser and for pages viewed in that browser all the http_referer values are as they should be. This is causing quite a headache for forms which redirect using this variable, as well as the logs which dump various environment variables to database for easy querying - and the guys who analyse the stats aren't remotely happy!
I have flagged this with the developer of CSS3 PIE and it's a mystery to him, but before I register a bug I wanted to see if it might be some failing of IIS or some setting I've missed in it (I'm using version 6 on Windows 2003). We have an Linux server with Apache as well for different purposes which I redesigned using the same technique and that doesn't seem to be displaying the same behaviour.
Does anyone have any related experience with PIE or any other .htc files on IIS which they were able to solve? Or is it some kind of IE8 bug that will never be fixed?
we experience the same issue. We removed it from the html. It could be an IE bug, I don't see any reason why the referer of the .htc should be the same as the page.
I have a very wierd problem and I dont know where to begin to fix it. I have tried my website on 8 computers using IE9 and for 2 of them the page doesnt show the correctly. I found out that when I take out the dropshadowextender it looks ok. So what I did is first try to go in cleared out all cookies, etc.. and then went into advanced settings to compare the ones that were working to the ones that were not, but that didnt work. I tried the site on all machines using FireFox on all computers and they work fine. My problem is what could it be causing those 2 computers to not show up correctly. I could see if it showed up wrong when I ran the site on all computers.
CSS3 Pie is a .htc file that, when placed on your server, provides extra code for IE so it can render many CSS3 styles on IE9, 8 and 7 properly.
Works well. Worth checking out.
I'm having a strange issue with Chrome.
I'm working on development with a very image heavy website. If I reload a page over and over again, eventually half the images or more will just disappear. (they don't seem to be broken, just not visible).
If I clear my local cache in Chrome and refresh the page, the images return.
Any idea what may be causing this and how to possibly fix?
edit: just to note, it's not just me. Others hav reported the same issue on the website I'm working on. Always Chrome.
Images, which contains "content-length" header randomly disapper, removing this at the server side solves this bug...
(chrome dev team has this issue in "open" state in their bug tracing system)
I've been getting this recently too. I generally use the latest dev channel for Chrome and assumed it was related to that, but even when launching the regular version of Chrome I get the same issue. I've only noticed it for the past 2-3 months though. Hard-refresh does the job, but it's a really odd bug.