IE 11 does not appear to display HTML5 output?

[AbbyMats]

Has anyone else run into this? We get the skin, but no content.

[AbbyMats]

This was originally a post by me to ask if anyone else has encountered a problem displaying HTML5 help in IE 11 (i.e., it doesn't display at all). It's actually not isolated to HTML5, becasue opening WebHelp is blank too. This issue is also related to other posts I've made in http://forums.madcapsoftware.com/viewto ... =9&t=17602 and http://forums.madcapsoftware.com/viewto ... =9&t=17418.

Here's what's happening: We have a machine with Windows 8.1 and IE 11 preview on it. When we try to open our HTML5 locally installed help, all that appears is a blank skin. No message to say that scripts or ActiveX controls disabled. No button to click to allow the content. Nothing. We generate our help with Mark of the Web enabled, and that does not help at all. Windows 8 seems to have gone farther with the local machine lockdown on local HTML files, which was evident when IE 10 came out, but even more so with seeing in this IE 11 preview.

Is Flare going to be able to provide solutions to this soon? Are there any simple things we can do on our side to avoid this? Adding something to our users' registry is not going to work, which was suggested to one of my previous posts.

Thanks,
Abby

[RamonS]

Did you try opening it from a web server? Or alternatively, did you add the Mark of the Web to the output? For IE you need to add the mark of the web (MOTW) in order for IE to display the content locally because then IE is made to believe that this is downloaded content that already went past the online security settings (so much for security when a single line can circumvent it). That said, once you turn MOTW on and have the help on a web server it won't work with IE.
In short, if you run it locally, you need MOTW for IE. If you run help from a server you need to turn MOTW off. All the other (real) web browsers do not have this issue, it is once again an IE special.

Also keep in mind, Flare V9 predates Win 8.1 and IE11. In fact, neither Win 8.1 nor IE11 are officially released. I do understand that you want to get ahead now that Microsoft bother to provide the RTM to developers.

If it is not fixed with enabling MOTW my suggestion is to contact support.

[AbbyMats]

Yes, MOTW has always been enabled in our output, and even with that, IE11 does not display anything other than the skin. It have noticed, though, that the only help file that does not automatically contain the MOTW statement in output is the *_CSH.htm file, and it needs to. Is this a bug? This causes the script/ActiveX message to show in pre IE11 versions when we access context-sensitive help from our dialogs. In any event, even if I manually add the statement to the CSH, content and the TOC do not display in the skin in IE11. I have not tried opening our help on a web server.

It would appear that to get help to work properly with both IE10 (which no longer takes you to your topic for context-sensitive help and opens only at the Home page) and IE11, we have to manually insert <meta http-equiv="X-UA-Compatible" content="IE=8" /> in the main .htm file and the _CSH.htm file, to emulate IE8. I suppose we could enter <meta http-equiv="X-UA-Compatible" content="IE=9" /> to emulate IE9, but I have not tested that yet.

Sounds like I at least need to contact support about the IE10 issues, since it's already released.

Thanks,
Abby

[ruthhoward]

This is a BUG!!!! I contacted MadCap support about it and got this response:

Please note that I have submitted a Bug Report on your behalf (#78846) with our development team and you will be notified via email if a fix for this is included in a future patch or release version.

We haven't found a viable workaround, but will keep you posted when we find one.

Here's what I observe:

* HTML5 output from Flare 8 or Flare 9 with MOTW does NOT work in IE11 on FILE:// access - get blank frames inside expected skin as others have described
* HTML5 output from Flare 8 (about to check 9 today) without MOTW works fine on HTTP:// access (including customizations to the skin javascript we've made)
* accessing using FILE:// across a network (e.g. from shares) is also broken (see quote below, support suggested that might work)

I haven't tested HTML5 + MOTW on over HTTP

MadCap's initial response was that Win 8.1 isn't out yet but it was - they just hadn't noticed!

Since the OS and version of IE is still in the beta phase, we need to wait until a full release is provided. The behavior is due to the "Enhanced Protected Mode" of IE. If the output is viewed outside(server) of the local machine, then the site is viewable.

Playing with "Enhanced Protected Mode" doesn't seem to help for FILE access.

A quick Google throws up this:

http://blogs.msdn.com/b/ieinternals/arc ... er-10.aspx

any other ideas anyone?

[ruthhoward]

More info....

I tried inserting <meta http-equiv="X-UA-Compatible" content="IE=8" /> into all files using the masterpage and into the main.htm and main_CSH.htm files and that works in IE11 for me on FILE://

[LTinker68]

* HTML5 output from Flare 8 (about to check 9 today) without MOTW works fine on HTTP:// access (including customizations to the skin javascript we've made)

I don't think WebHelp output with MOTW has ever worked via http://, and I wouldn't expect it to with HTML5 either. MOTW's purpose is to trick IE into thinking it's going to a web server, but that same code screws up viewing on an actual web server. Or at least IE viewing the help on an actual web server; I don't think you have a problem if you try to view it through Firefox or Chrome, although I haven't tried it on a web server that had MOTW included in the topics. I know viewing help locally without MOTW doesn't affect Firefox or Chrome.

So to test IE, I have two targets in my projects, one with MOTW turned on and one with MOTW turned off. During initial dev I build the first target, then when ready to post to the website I use the second target. I also have publish set up to publish the second target but I don't publish the first target, because it's just going to my local machine. And if I try to publish without first building, then Flare will ask if I want to build the target, so it uses the target without MOTW.

[RamonS]

As far as Win8.1 goes, Dell is already delivering new gear with 8.1 on it although the official release date is October 17th! Anyone claiming that Win8.1 isn't released yet or still in beta is not correct. RTM was made available on MSDN about a month ago and it was pushed to OEMs even weeks before that. By all practical means Win8.1 and IE11 are here, present, released....and as buggy and craptastic as the previous versions. We get a new version of IE and still have pull tricks just to make things work on IE that work fine without acrobatics on every other browser.

[ruthhoward]

Just got a reply about this from MadCap support:

Our developers have been working diligently in finding a resolution and we are anticipating an software update with Flare in or around the official launch of IE 11.

[rob hollinger]

Yes we are working on an update to Flare 9 which should be ready to release approximately the same time IE 11 is released to the public.


Ruth,
From msdn, you might want to use this code:
<meta http-equiv="x-ua-compatible" content="IE=edge" >

http://msdn.microsoft.com/en-us/library ... s.85).aspx

Use the following value to display the webpage in edge mode, which is the highest standards mode supported by Internet Explorer, from Internet Explorer 6 through IE11 Preview.
<meta http-equiv="x-ua-compatible" content="IE=edge" >
Note that this is functionally equivalent to using the HTML5 doctype. It places Internet Explorer into the highest supported document mode. Edge most is most useful for regularly maintained websites that are routinely tested for interoperability between multiple browsers, including Internet Explorer.
Note Starting with IE11 Preview, edge mode is considered the preferred document mode. (In earlier versions, it was considered experimental.) To learn more, see Document modes are deprecated.
Starting with Windows Internet Explorer 8, some web developers used the edge mode meta element to hide the Compatibility View button on the address bar. As of IE11 Preview, this is no longer necessary as the button has been removed from the address bar.
Because it forces all pages to be opened in standards mode, regardless of the version of Internet Explorer, you might be tempted to use edge mode for all pages viewed with Internet Explorer. Don't do this, as the X-UA-Compatible header is only supported starting with Internet Explorer 8.
Tip If you want all supported versions of Internet Explorer to open your pages in standards mode, use the HTML5 document type declaration, as shown in the earlier example.

[ruthhoward]

Thanks Rob. I'll try "edge".

Quick question... if I'm compiling a HTML5 target using Flare, why isn't the doc type HTML5 automatically?

<!DOCTYPE html>

surely that would have solved this problem from the beginning? I find it a little odd that HTML5 target -> html not html5

thanks!
Ruth

[rob hollinger]

Maybe I'm missing something.
I build an HTML5 target and open the output folder.
When I view each of the htm files in a text editor, I see <!DOCTYPE html> on the top of each page.

[ruthhoward]

Tip If you want all supported versions of Internet Explorer to open your pages in standards mode, use the HTML5 document type declaration, as shown in the earlier example.

sorry, am I having a mental block? I understood the above to mean that I could somehow get <!DOCTYPE html5>

If HTML5 doc type is actually <!DOCTYPE html> then I already have that and its still broken in IE11.

I also tried IE=edge and that doesn't work. That forces IE to uses the highest possible version - which in IE11 is IE11 - so I get the nice NULL window:

IE11.jpg

(NB I'm having the same conversation with Marvin in support )

[rob hollinger]

two things will happen for IE11 support.

Mark of the web becomes:
<!-- saved from url=(0016)http://localhost -->
and
<meta http-equiv="X-UA-Compatible" content="IE=edge" />

Both of these need to be done in the output for IE11 to work properly.

[techwriter31]

Hi all,

Not to hijack this topic, but we're also having problems with our CHM files that installed/launched from our software application. We've found that if the user has IE9 installed with compatibility mode turned off and then use F1 in the software to launch the CHM, after closing the CHM and attempting to exit the software application, everything hangs and the software application actually crashes.

I figured I'd give this a shot, so I created a master page and added the following compatibility mode meta element to the header, to specify the legacy document modes:
<meta http-equiv="x-ua-compatible" content="IE=7,8,9,10" />

(I originally set the IE value to “edge”, as edge mode places IE into the highest supported document mode supported by IE. However, according to MSDN site, it sounds like the x-ua-compatible header is only supported in IE8 and higher, and I believe some of our Windows XP users might be using IE7).

After adding this to the master page, regenerating the CHM and dropping it into the appropriate installer directory, our software application no longer crashes!

However, I believe this meta element is typically used for webpage rendering. Is it "safe" to use in CHMs as well?

Thanks in advance!

[RamonS]

However, I believe this meta element is typically used for webpage rendering. Is it "safe" to use in CHMs as well?

I'd say so because the CHM viewer is more a wrapper around the IE rendering engine.

[techwriter31]

Thanks RamonS!

[NorthEast]

(I originally set the IE value to “edge”, as edge mode places IE into the highest supported document mode supported by IE. However, according to MSDN site, it sounds like the x-ua-compatible header is only supported in IE8 and higher, and I believe some of our Windows XP users might be using IE7).

I'm a bit confused why you're using this method instead of 'edge'. I understand x-ua-compatible only works for IE8 (and later) too, but this would mean it has no effect on your IE7 users. Setting IE=7 just tells IE8 (and later) to render pages as IE7, it shouldn't make any difference for IE7.

[ruthhoward]

Hi Kellie

That sounds like a really odd problem. I thought that the CHM viewer on Windows came with its own embedded IE (version6 or earlier I think).

We had a problem using p.style:before definitions in our CSS where that content wasn't rendering in CHM output (fine in HTML5) - it turned out that the p.style: before syntax isn't supported earlier than IE7 (if I recall). So even though we were opening the CHMs on machines with IE 7/8/9/10 installed, the text embedded in the style definition in the CSS wasn't rendering because the CHM viewer was using its own internal very old IE.

We put in a workaround by using a linked stylesheet and some javascript, but your comments are making me wonder whether the <meta http-equiv="x-ua-compatible" content="IE=9" /> element I put into my masterpage to sort out the IE11 issue might also resolve my CHM/CSS problem and I can remove the workaround.

Thanks so much for the info and advice! it may well come in really useful.

Cheers
Ruth

[RamonS]

I could not find any info which IE version the CHM viewer uses. But from what I did find it uses whatever version is installed on the system to execute the hhctrl.ocx ActiveX component. There is a total of four files that provide the CHM help viewer (%windir%\HH.EXE (not registered), %windir%\system(32)\HHCTRL.OCX (registered), %windir%\system(32)\ITSS.DLL (registered), %windir%\system(32)\ITIRCL.DLL (registered)).
The problem is that Microsoft did absolutely nothing to this platform for over ten years, yet it is still the recommended format for Win 8.1 for desktop help. Web Help is a different story and not tied to IE.

[techwriter31]

I'm a bit confused why you're using this method instead of 'edge'. I understand x-ua-compatible only works for IE8 (and later) too, but this would mean it has no effect on your IE7 users. Setting IE=7 just tells IE8 (and later) to render pages as IE7, it shouldn't make any difference for IE7.

I agree; I realized this too last night after I had a moment to really stop and think about it. It was a bit frenzied yesterday... Thanks!

[AbbyMats]

two things will happen for IE11 support.

Mark of the web becomes:
<!-- saved from url=(0016)http://localhost -->
and
<meta http-equiv="X-UA-Compatible" content="IE=edge" />

Both of these need to be done in the output for IE11 to work properly.

How is this supposed to work when we need to support multiple versions of IE? Do we have to have both the old and new MOTW tags in out output? Or, will the new MOTW tag replace the old for any version of IE and still work? IE 11 comes out this week, and with our software wrapping up in a few weeks, I hope we aren't going to send something out that isn't going to work in IE 11 again.

Also, I thought I tried IE=edge and it did not seem to help.

Thanks,
Abby

[RamonS]

That is supposedly now fixed with Flare V 9.1.2

[pjnut]

I am just now running into a similar problem since this is the first time I am generating HTML5 output. When I view my HTML5 help locally, it displays in IE9 standards, IE9 document mode. When I view on our web server, it displays IE9 standards, IE7 document mode.

I tried selecting MOTW and it didn't help. I also tried adding the <meta http-equiv="X-UA-Compatible" content="IE=edge"> tag to my master page; but, that didn't work either. Do I need to add the meta tag to every topic in the project (that is what my developer recommended)?

[ruthhoward]

You can add that to every topic automatically, by putting it into your masterpage. Getting it into all topics was part of my solution to this issue.