My Webpages are behaving differently in IE-7, IE-8, IE-8 Compatibility Mode and IE-9. Navigation from one page another is not taking place in few versions of IE and styles are not getting applied on few versions. What should I add into my code so that my Webpages opens properly in all the versions of IE.
do you have
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
at the top of the page with no extra line?
Related
I have come across an issue when I add a TWebBrowser to a Delphi form and then load a webpage either from file, i.e. wb1.Navigate('file://myhtml.html'); or navigate to the exact page stored on a website, i.e. wb1.navigate('http://mysite/myhtml.html');
It seems to process the CSS differently whether I load the page locally or from the website in IE itself!
I have made sure the page has <!DOCTYPE html> which is meant to force IE9 as a minimum from what I have read.
Anyone seen anything like this before?
This is what it looks like if I load the page using TWebBrowser:
In IE, it displays the data correctly side by side horizontally.
Thanks. It was the compatibility mode that was the issue.
Internet Explorer 10 has built in spell checker and it works just fine. I tried to create a small HTML page to test it with following contents:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML lang=en xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"><HEAD>
<META name=GENERATOR content="MSHTML 10.00.9200.16721"></HEAD>
<BODY spellcheck=true contentEditable=true style="MARGIN: 0.5em">
<P>Theze ara mispeled wordz</P>
</BODY></HTML>
All that is needed is to put properties spellcheck=true and contentEditable=true.
I also tried adding <meta http-equiv="X-UA-Compatible" content="IE=10" /> e.g.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML lang=en xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"><HEAD>
<meta http-equiv="X-UA-Compatible" content="IE=10" />
<META name=GENERATOR content="MSHTML 10.00.9200.16721"></HEAD>
<BODY spellcheck=true contentEditable=true style="MARGIN: 0.5em">
<P>Theze ara mispeled wordz</P>
</BODY></HTML>
For that matter, using IE=edge instead of IE=10 doesn't make any difference:
What does <meta http-equiv="X-UA-Compatible" content="IE=edge"> do?
I then tried adding setting FEATURE_BROWSER_EMULATION to registry:
http://www.west-wind.com/weblog/posts/2011/May/21/Web-Browser-Control-Specifying-the-IE-Version
This improved rendering of certain elements which had CSS styles like border-radius so at least I could see it is in IE10 mode, but still no spell checker.
The above page works in Internet Explorer browser and spell check is working.
However, when same content is loaded into TWebBrowser (I use TEmbeddedWB but it is just the same wrapper anyway) it doesn't work.
After googling and googling for solutions, still haven't found one. Do you know is this even possible in WebBrowser control? I need the solution that would work on Windows 7 not just Windows 8. I've seen the registry entry FEATURE_SPELLCHECKING but it applies only to Windows 8.
Are there any alternative solutions that would work within DesignMode of TWebBrowser control? I am looking for curvy red underline thing like in Word or other programs and possible GUI window to offer alternative words.
I think you are out of luck here.
There was a bug report on Microsoft Connect concerning FEATURE_SPELLCHECKING and windows 7. Unfortunately it has been closed "as Designed".
This is the official answer from Microsoft:
Thank you for your feedback.
After additional review, the spelling feature is only supported on
Windows 8 and higher and is not supported on Windows 7. This is
because the spelling feature was built into the Windows 8 platform.
Best regards,
The Internet Explorer Team
try to change it in the registry...
Bye
Nicolas Perichon
HKEY_LOCAL_MACHINE (or HKEY_CURRENT_USER)
SOFTWARE Microsoft Internet Explorer Main FeatureControl
FEATURE_BROWSER_EMULATION
contoso.exe = (DWORD) 000090000
10001 (0x2711)Internet Explorer 10. Webpages are displayed in IE10 Standards mode, regardless of the !DOCTYPE directive.
10000 (0x02710) Internet Explorer 10. Webpages containing standards-based !DOCTYPE directives are displayed in IE10 Standards mode. Default value for Internet Explorer 10.
info de Microsoft:
msdn.microsoft.com/en-us/library/ee330730%28VS.85%29.aspx#browser_emulation
We are having issues where IPAD IOS 6 not displaying Report in Telerik Report Viewer.
We have an MVC ASP.NET application which calls the ReportViewer.
But Report Viewer does not display the report when the 'Preview' button is selected.
Can you suggest how I can display the telerik report in IPAD IOS 6. Hint: It works in IPAD IOS lower versions than current new version.
Thanks in advance.
I am quite sure that by now you have solved your problem. However, for other people experiencing the same, the problem is often caused by the document being rendered within an iframe and the page uses HTML5 DOCTYPE. I have resolved this issue changing this:
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
.....
to this:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
.....
as recommended here.
I am currently trying to add basic JSF (2.0) support to Backbase Portal 5.2.1.2 to use in my custom widgets.
It seems to be working when I access my widget in a static way (e.g. ".../portal/static/portal_name/widgets/widget_name/index.xhtml"), but when I view my widget in the context of a portal (.../portal/portals/portal_name/pages/index) my JSF tags are shown in the HTML source as instead of the parsed output. The same happens to EL variables like #{msg.title}.
If I use the same JSF setup in a 'normal' webapp project, it works just fine as well, so in my eyes, there must be something Backbase specific that is causing this issue.
I would like to know what is causing this to happen, if it could be solved or circumvented or if anyone has successfully managed to implement JSF in this specific version of Backbase. I know implementing JSF worked in Backbase 5.1, but for me it's not an option to revert to that version.
Edit - Added the widget's index.xhtml by request (My actual index.xhtml is slightly bigger, but this fails as well):
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core" xml:lang="en">
<h:head>
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />
<title>Help ribbon widget</title>
<link rel="stylesheet" type="text/css" href="css/style.css" />
</h:head>
<h:body>
<span class="left title">#{msg.help_title}</span>
<h:outputText value="TEST"/>
</h:body>
</html>
Additionally I am using a Border_Layout for my container template if that is of any help.
When I go to Google Chrome inspector's network tab, and look at the request for the widget's index.xhtml file, I can see the correct output, but for some reason this is not the same as what is shown in the combined html.
The problem with this approach is that widget definitions are not currently expected to contain dynamic content.
I'd guess that in your scenario, the *Border_Layout* container is server sider rendering (SSR) the widget. When this happens, if your widget's src URL is relative, the portal will simply read the file from disk and the faces servlet will never be invoked. This is normal, the definition is expected to be static. But there are two immediate solutions:
Firstly, you can switch to client side rendering (CSR). This will result in the client making a http request for the widget definition and it being accessed via the faces servlet. Easiest way to achieve this is to use a custom page template which does not contain a <b:include> tag. This solution does mean it will not work with JS disabled though.
If, however, you wish to keep using SSR, you can use an absolute url for your widget's src property. This means the server needs to make an http request for the widget, thus running it through the faces servlet. There is one more problem here; As the Portal Server expects widget definitions to be static, it will aggessivley cache it, so you'll need to switch off widget caching.
I wouldn't really recommend both of these solutions though in the longer term. I'd recommend you run your JSF app independently in a separate context and then find a way to include it in a widget. You could try to setup something with Backbase Mashup Services, but I'd recommened a simple iframe approach. If you require, I can provide you with a more advanced iframe Backbase widget for creating seamless iframes (no scrollbars etc).
If you need any more support, I'd encourage you to sign up at https://my.backbase.com. Backbase's new support site where you should receive more dedicated help, docs and code samples.
I've created a website that displays correctly in all browsers including IE8 when viewed from my local server i.e. http://localhost
However when I view the website from another machine, http://pc5008 for example, IE8 goes into what seems like compatibility mode and looks terrible.
Extra Info
When viewed from the localhost IE8 gives an option to view in compatibility mode. If I choose this option it looks the same as when viewed on the non-localhost i.e. terrible.
When viewed on the non-localhost IE8 doesn't show the option to view in compatibility mode. (compatibility mode under Tools is greyed out)
Also, everything validates as XHTML 1.0 Strict.
I'm not very familiar with the subject, however as I know IE chooses it's mode (standard/quirks-mode) based on doctype declaration. Check if your doctype is correct.
Maybe this article will help: Activating Browser Modes with Doctype.
If the problem is eventually with doctype, try declaring it html5 style:
<!DOCTYPE html>
In turns out that IE8 has an option under Tools\Compatibility View Settings\ called 'Display intranet sites in Compatibility View'. Disabling this feature fixes my problem.
Another solution is to add the following line to the head:
<meta http-equiv="x-ua-compatible" content="IE=8">
This overrides the setting.