When using MHTML over https in IE7, IE7 shows the non-secure items popup.
I believe this is due to the mhtml: prefix. IS this actually a bug? or is there a workaround for it?
Starting here is a good thread kind of explaining some options. We just ended up not supporting IE7 since it's only a couple percent of our users now anyway.
http://www.phpied.com/mhtml-when-you-need-data-uris-in-ie7-and-under/#comment-72154
Related
Firefox runs my website significantly slower than IE or chrome. When I check the network tab, I see that 235ms is spent blocking. No blocking is reported for my site in chrome, and no blocking is reported in firefox for other sites, like google or amazon. It also has a much higher receiving time than chrome.
Its my understanding that blocking occurs because the browser has a limited number of connection that it can make:
What is meaning of 'Blocking' in Firebug Net Panel?
Here's an example of a website blocking before the document: http://thehill.com/ (sorry in advance for the politics). The blocking on this site doesn't always occur (it does on my site) and is about 1/10th the length of the blocking on my site.
Shouldn't the browser always have all its connections available when it tries to download the Document? Why would firefox be blocking on the document and not chrome, and how can I fix it?
Firefox has it's own http proxy settings. IE and chrome take proxy settings from windows settings. Please check if there is some difference between your FF and IE settings.
Next thing you can do is creating new, fresh profile in FF (make sure there is no addons installed) and trying again.
try making your javascript calls asynchronous. My wild guess (with no codes provided that is the only thing possible) is that you have some javascript call that is blocking. try optimizing and debugging javascript, maybe that will help you see where did the blocking appear.
If I use the F12 Developer Tools to debug for IE, can I depend on the "Browser Mode" and "Doctype" to debug issues for IE8 and below?
By debugging I mostly mean for overall page behavior... HTML/CSS, A client says "The dropdown doesn't work in IE8", I have IE9... Instinct is to hit F12 and change the doctype or browser mode and test.
Short answer, no.
I would not recommend using compatibility mode. I have never quite understood why MS doesn't seem to do what Mozilla and Google do which is, disallow the use of deprecated tags. As an example, at my work, we have two tiers of browser usage, tier 1 and tier 2. Tier one consists of: Safari (oddly enough, we get quite a few customers buying via their iPads), Chrome, Firefox and IE9. Tier two is: IE8 and the rest of the pile. Recently, we had a bug where some checkboxes where not rendering correctly in **only IE8**; but worked fine in IE7 and IE9. The moral here is that using compatibility mode is testing under an assumption, and if you want thorough and correct testing, you cannot assume anything.
You can try to use the Quirks mode, but that's not 100% the same. If you are lucky, you will hit the same bug also in quirks mode.
The only sure way is to use a IE8. There are cross-browser testing tools that enable you to do so without any installs.
Just for bug reporduction purposes http://www.modern.ie/virtualization-tools offers some VM-s you can use.
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've been using the service from webtype.com to render fonts on a website, but now the fonts stopped loading in Firefox (tested this on Firefox 3.6 and 4.0). It works just fine on other browsers.
After some searching, I've found that a possible explanation could be the same-origin policy in Firefox. But the only solution I've found was setting the Access-Control-Allow-Origin on the server that's providing the service, to which obviously I don't have any access to.
Has anybody else encountered this problem? How did you solve it?
Thank you.
That's the only solution, yes. Or using a same-origin font.
If webtype.com is not returning that header, that sounds like a bug on their end that you should report to them.
Hi i have made a website. And cause of some crazy reason i don't figure out the ie8 runs it with Browsermode: i8 and Documentmode: ie7 (standard). Why he doesn't use ie8 for both?
Did you put a valid DOCTYPE into your pages? Otherwise IE8 will run in compatibility mode.
See this blog post for details.