How to activate in my code : microsoft cpmpatibility mode :
I would like, when a visitor come to my site to get his browser forced to be in compatibilty mode.
To force IE's compatibility mode, use the following in your page header:
<meta http-equiv="X-UA-Compatible" content="IE=7" />
This will force IE8 and above to render the page using IE7-compatibility mode. (You can also specify IE8-compatibility mode if you need that for IE9)
You can't change the compatibility mode from within your code after the page has loaded, so it can't be done using an ajax call; it has to be in the <header> section of the main page load. (I mention this because you have ajax in your tags for the question).
Now that I've explained how to do it, I would like to add that it's generally considered a bad thing, unless you have a specific need for it. If a site is written in a way that means it doesn't work in a newer version of IE then it also probably doesn't work in other browsers. This indicates poor code, and it would probably be better to actually fix it than to apply the quick and easy way out of using the compatibility mode.
The only times when compatibility mode is recommended are when you are maintaining an existing web application based on an internal intranet where it won't be seen outside of the local network. In this case, compatibility mode can be helpful in making it possible to upgrade the browsers in the network without having to make large changes to the web apps.
But in an intranet environment, you can also control compatibility mode in the browser preferences, without having to use the meta tag.
Finally, you should also note that compatibility mode is not the same as running the old version of the browser. There are bugs and quirks in compatibility mode which do not appear in the real thing. It mostly works, but you should test thoroughly.
Related
Can someone explain me why TWebBrowser control is working so slow on all XE editions of Delphi including XE5 and possibly XE6? To test this you need to create a new Delphi project and put TWebBrowser control in it. On form show event, navigate to this website:
http://ie.microsoft.com/testdrive/Performance/setImmediateSorting/Default.html
Please test this on Windows 7 or later. When navigation is complete, run setImmediate test and watch the results. It will take huge amount of time to complete the test. It will take about a minute to finish this.
When you open true Internet Explorer browser and do the same thing - test will be completed instantly (~200 miliseconds).
Some additional wierd informations:
When you recreate this procedure on old versions of Delphi (Delphi 7 to be precise) the web-control works as fast as it should be working and test is completed instantly. But the HTML5 speed test will still works slow (alternative test on this page).
Another weird thing is, the same slow behavior can be seen on C++ Builder but not in Visual Studio products. Is Microsoft deliberately slowing down the TWebBorwser in Embarcadero products?? I can't belive this.
I was trying to overcome this problem with diffrent methods such as:
Trying different feature options in registry such as:
FEATURE_GPU_RENDERING,
FEATURE_BROWSER_EMULATION (11001),
FEATURE_ALIGNED_TIMERS (undocumented option),
FEATURE_ALLOW_HIGHFREQ_TIMER (undocumented option),
Setting timerBeginPeriod(1) - no effect.
Please, if someone have any clue how to fix this issue - share this information with me.
UPDATE1
I made standalone test app if anyone cares. It can be downloaded here: http://mp.org.pl/download/ietest.zip It contains source and exe app with htm file. HTM file contains some js procedure that works 10 times faster in standalone IE than in TWebBrowser control. It uses setImmediate as a test (the same procedure used in test described above). But it can be easier for testing this way.
I can also see the behavior described (in your original post and in the comments). I have a few thoughts, but not necessarily an answer.
One should expect some difference in performance between the WebBrowser control and IE, in part because your Delphi app will need to build in support for certain features/APIs that IE supports out of the box.
For example, the WebBrowser control fires notifications related to tabbed browsing (old, but relevant), but it does not intrinsically handle those notifications or update the UI. You have to respond to the notifications and draw the tabs yourself. By default, IE is hardware accelerated and uses certain Windows APIs that may not be directly supported by Delphi's VCL (for resource/performance) reasons. (Hardware acceleration could account for some of the performance differences you've noticed.)
(And, for the record, I don't believe a list of differences between IE and the WebBrowser control was ever documented. I certainly don't remember seeing one in the portfolio.)
Also, the default values for various feature controls vary between IE and applications hosting the WebBrowser control. Part of the reason for this stems from the idea that IE needs to highlight performance over compatibility whereas applications generally need to emphasize compatibility over performance. You may wish to review the feature control reference to see if there are other FCKs you need to enable for your app.
Second, your loops are very tight, perhaps too tight. You've got one request piling on earlier requests and you're not really leaving much room for processing, even with setImmediate. (IIRC, we're not really supposed to use anything smaller than 250ms for setInterval without risking performance hits from the sheer number of requests.) The remarks in the setImmdiate ref. page provide some guidance, as does this article on requestAnimationFrame.
One reason why dragging the window appears to improve performance may due to the priority of window drag repaint requests. They may be forcing your loops to hold long enough (or even break) to allow other events to process. Hard to say without with tracing the system with a debugger.
Have you ever had to add application.processMessages() to your Delphi apps in order to allow the system a chance to handle the work you've already assigned? A similar need may be coming into play given the nature of your test.
Performance testing and timing is a tricky thing. You need to make sure the test isn't imposing so much overhead that it interferes with the actual work you're trying to perform.
Finally, there were some questions about the document mode of the page as it's loaded into your project. When I first started messing around with your sample, I couldn't get project4 to load slowtest.html in anything other than IE5 quirks mode (notoriously slow). Here's what eventually started working for me:
<!DOCTYPE html>
<!-- saved from url=(0023)http://www.contoso.com/ -->
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge"/>
<script type="text/javascript">
...
(Note, I deleted your initial doctype declaration and rewrite it to resolve a syntax error that was being reported by the F12 tools debugger.)
A few style key points here:
I used a mark of the web to load the page in the Internet zone. I find this makes it easier to load the page in edge mode, as pages in the intranet zone are loaded in compatibility view by default (unless you map the zones differently).
The x-ua-compatible header needs to be one of the first in the head block. It can follow title, but not much else.
Stylistically, elements need to be specified in lower case these days. There's a possibility that not following the current conventions forces the parser to fall back to an earlier rendering that supports the conventions.
Once I was able to control the documentMode at runtime, I found results I expected: older document modes ran more slowly. I also found that using requestAnimationFrame instead of setImmediate led to even better performance, but also surfaced the timing issue almost immediately.
In the end, this may be a case where the test highlights a problem, but not necessarily one you're trying to solve. (Insert Inigo meme here.) I get that you're trying to resolve a bottleneck. Are you sure you've found the correct bottleneck?
You may not be able to replicate the same performance of the native browser, but perhaps you can refactor the code to perform adequately without the extra overhead? Is there anything that might be better handled with a worker or some other implementation technique?
Hope this helps...
I have a page which displays around 1000 records.
The page gets loaded quite easily on firefox..around 2 seconds. But same on IE taking more that 10 seconds.
I checked performance tuning on server side, and modified the hibernate Criteria query returning this whole data. But issue is still there.
I also tried to remove almost all the plugins from IE thinking those could be the culprits. But no impact. :(
Trying to monitor the UI components on IE developer tool, but didnt find much details.
Any suggestions please. :)
Thanks in Advance :)
Performance issues like this will be down to rendering the UI. The server side processing won't vary from browser to browser, so it will be down to the way different browsers handle the drawing of the elements. Without seeing your page in action it is not easy to suggest anything to help improve your situation.
Guys Got the Culprit here... :) :)
After doing lot of RnD on Server side and Client side, I took a look at "Developer Tool" in IE.
You can find something like "Document Mode: Quirks". If you check the Wiki page for this Quirks mode, You can find a definition as "In computing, quirks mode refers to a technique used by some web browsers for the sake of maintaining backward compatibility with web pages designed for older browsers, instead of strictly complying with W3C and IETF standards in standards mode."
So this all becuase of checking for compatibility for all components on page. And hence the performance issue. :)
And When I changed this mode to IE 8 Standard. Things started working really well.
IE and its issues ...!!!! :D
Is there anyway to detect old browsers in HTML like the code I use for IE e.g :
<!--[if lt IE 9]>
...
<![endif]-->
I want to show a warning message as some of my web features are not supported for them.Is it better to use a JavaScript to detect this instead ?
Thanks
I finally used the code found at
http://www.php.net/manual/en/function.get-browser.php#92310
by using PHP
Feature detection. Not browser detection.
If you want to warn them about missing web features, why not use feature detection for those specific features, rather than browser version detection?
This has two major advantages:
Firstly, for your code, it has the advantage of making it clear what you're actually doing, and why you're doing it. This will make your code easier to work with in the future.
Secondly, this will allow you to reliably pick up all browsers that don't have the feature(s) you need, which means that if someone visits your site using (for example) and old mobile phone browser that's never been updated, you'll still be able to pick it up and show the correct message, even though you never thought to test for that specific browser.
You didn't tell use which specific features your site needs, so I can't give you details of how to detect it, but you may find the Modernizr library useful; it does feature detection for a wide range of modern browser features.
You may also have the option to add a 'polyfill' to your site to add support for the missing feature to old browsers. Modernizr is good for helping with this, and they also have a big list of polyfills you might like to try.
Hopefully this question isn't as subjective as I think it may be.
I have an Intranet application which needs to work with IE8 as the enterprise is replacing IE6 as the standard browser.
Our testing team found that it did not work in IE8, little did they know that it actually did. Their browsers were set to run IE8 in compatibility mode for Intranet applications.
I found that if I set the meta tag for X-UA-Compatible to IE=EmulateIE8 that I could force the browser to render this application as IE8 and the application worked fine.
Are there any pitfalls that I don't know about for this solution? If so, is there a better solution?
Setting X-UA-Compatible to IE=EmulateIE8 will make the upcoming IE9 behave like IE8.
Initially, this may be what you want. If you're not in a position to fully test against IE9 when it comes out (sometime next year, I presume), it may help should the organization upgrade to IE9 immediately.
When you've fully tested everything, and want the application to work in IE9's native mode, you'll be a little bit stuck. You could set X-UA-Compatible to IE=IE9, and IE9 will work fine, but what does that mean to IE8?
That's all speculative though. Right now, it won't harm anything. If you need to make changes to handle later versions of IE9, you can do that later.
When designing and building the UI for an application that uses AJAX, when do you consider graceful degradation (for users who have JavaScript disabled, or are using a screen reader)?
At the end, once the AJAX version of the site is completely finished
At every stage of development
I don't
Something else...
These days, progressive enhancement is generally preferred over graceful degradation - i.e. the exact opposite approach.
The method I'm employing so far is to write it so it works without JavaScript and then add the JavaScript on top.
It's really the reverse of graceful degradation. It's an emphasis on enhancing the page as your browser and settings allow.
Relevant article
Graceful degradation can describe two things:
It is a behaviour (normally a website or web application) that allows the site to continue functioning when certain features are disabled (e.g., JavaScript; CSS).
It is an approach that builds the application to work with bells and whistles turned on, and then afterwards fixes are bolted on to make it work without said noisemakers.
I assume you are asking whether or not to use the latter to achieve the former. I'd definitely suggest achieving 1), as anyone who browses with JavaScript off (i.e., lots of people with a computing clue; those using text-based browsers; those using disability aids) will otherwise not be able to use your site.
As for how to do it, A List Apart have a great article on progressive enhancement which is worth looking at, where you build the site to work basically first, and then you add the AJAX, etc. afterwards. I prefer this approach because it gives the app a solid foundation to work on, with decent security and functionality from the word go. Future enhancements to it can be made at the basic level and then added into the AJAX layer; without the former, it's harder to add in gracefully degrading components to the application in the future.
Anyway, enjoy the article and if you want to know more about this stuff generally, A List Apart is a great site!
Jeremy Keith sums up the argument for progressive enhancement with his Hijax article.
Typically, I use the following code to dynamically apply a class of "js" to the HTML element to target JavaScript-enabled browsers
<script type="text/javascript">if(h=document.documentElement)h.className+=" js"</script>