Home/ Questions/Q 8687595
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-12T23:09:19+00:00

I have an iframe that I’d like to use to display instapaper articles to

  • 0

I have an iframe that I’d like to use to display instapaper articles to the user in my WinJS “store” app. A very high-priority feature of this is that users should be able to read articles downloaded and saved while offline.

Not getting into all of the absurdities that make displaying a locally cached html file harder than displaying any arbitrary html document from the web, my current problem/question is with the iframe and how it treats html text.

Say I have an html document in a string read from a text file, like so:

  <html>
     <head>
     <title>Foobar!</title>
     </head>
     <body>
          <h1>Foo</h1>
         <div>Bar</div>
     </body>
   </html>

If I set a <div> element’s innerHTML property (via WinJS.Utilities.setInnerHTMLUnsafe method), then inspect the property, I get the output I’m expecting: 

>document.getElementById("article-frame").innerHTML
"
<title>Foobar!</title>
<h1>Foo</h1>
<div>Bar</div>
"

Now, when I do the same thing only using an <iframe>, this is the result:

>document.getElementsByTagName("iframe")[0].innerHTML
"&lt;html&gt;
&lt;head&gt;
&lt;title&gt;Foobar!&lt;/title&gt;
&lt;/head&gt;
&lt;body&gt;
&lt;h1&gt;Foo&lt;/h1&gt;
&lt;div&gt;Bar&lt;/div&gt;
&lt;/body&gt;
&lt;/html&gt;"

Obviously, the iframe is HTML-encoding the text, while the div is not.
Is this by design, and if so – why on earth would the behavior be so drastically different? I don’t remember ever seeing this sort of behavior from iframes but then again, it’s been a number of years since I’ve had to use one. I would prefer not to just use a div, since I can’t prevent the CSS from bleeding into it (I can prevent CSS from bleeding the opposite direction via appending element ID’s to embedded stylesheets however that doesn’t help the UX very much).

I’ve already spent a ridiculous amount of time on trying to get an iframe to load via the src property a file stored in a user’s appData, without success. These continuing hinderances can get very frustrating!

EDIT:
I’ve attempted to set the innerHTML property of the frame’s contentDocument property with results similar to the div experiment, except that the HTML is not displayed or rendered.

Interestingly as well is the output of checking the innerHTML property of both the contentDocument and the iframe (note the empty result for the latter):

> document.getElementsByTagName("iframe")[0].contentDocument.innerHTML
"<html>
<head>
<title>Foobar!</title>
</head>
<body>
<h1>Foo</h1>
<div>Bar</div>
</body>
</html>"
> document.getElementsByTagName("iframe")[0].innerHTML  
""

refrences
http://technet.microsoft.com/en-us/subscriptions/hh781229.aspx
http://social.msdn.microsoft.com/Forums/en-US/windowsstore/thread/e13791b2-7fc3-40cb-a284-f927aaa3a9e3

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think I figured it out.

    The key was that I wasn’t initially setting the src attribute on the iframe in my markup. Because it wasn’t set, iframe.contentDocument wasn’t getting created and set.

    Here’s the solution I ended up with. Setting the src property ensures the contentDocument property gets created:

    <iframe id="article-frame" src="about:blank"></iframe>

            var frame = document.getElementById("article-frame");
        Article.getFileText(book).done(function (text) {

            MSApp.execUnsafeLocalFunction(function () {                    
              frame.contentDocument.write(text);
            });

    I don’t think that I have to wrap the call to contentDocument.write() in the execUnsafeLocalFunction call, but since I also trust (within limits of reason) the input, I don’t think it hurts – I’ve noticed little js snippets for font downloading and display.

    • 0