locked
APPHOST9613: The App Host was unable to navigate to some link due to the following error: FORBIDFRAMING.

Answers

All replies

  • Hi Sars,

    These sites have set the X-Frame-Options header.  See this for more information:

    http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx

    -Jeff


    Jeff Sanders (MSFT)

    Monday, March 19, 2012 1:06 PM
    Moderator
  • Regretting the HTML5 dev path due to this. If my app were built in XAML, I could open YouTube links (for example) in a web view (as Tweetro can today, I checked). My app is aiming for a similar implementation of web content as theirs). But because I chose HTML5, I am hindered with no recourse by a measure designed to prevent clickjacking attacks on malicious websites. Apps are not websites, yet your runtime doesn't seem to recognize this. If it's OK for a XAML app, shouldn't it also be OK for an HTML5 app? I guess I'll have to try to catch this error and offer users to view the link in a browser. Not very "fast and fluid", and certainly a compromise. Sinofsky weeps.

    EDIT: I've got a workaround working. I wish I didn't have to do this. http://t.co/0hf6lkk1

    • Edited by pierce1161 Wednesday, July 04, 2012 2:23 AM
    Wednesday, July 04, 2012 12:13 AM
  • This seems like a reasonable thing to me since the runtime (and perhaps the developer) cannot be sure of what HTML is being rendered.  Imagine a scenario where the HTML being rendered might display other third party content.

    At the very least this seems reasonable, even if reasonable people can disagree. 

    Wednesday, July 04, 2012 7:25 AM
  • I hope it doesn't remains like this... and the WebView control (XAML) limitations are also lifted in future. One cannot possibly make competitive news and social applications compared with iPad. It certainly allows more freedom with WebView control.
    • Edited by gaurav77 Friday, August 24, 2012 6:15 AM
    Wednesday, July 18, 2012 1:28 PM
  • I agree with Pierce1161 because if it works in a xaml app, it should work in html5 app too. It would have been great if Microsoft had done some research on how other implementations are doing it already. I am referring to Firefox addons. They differentiate between the web context and the browser context and can clearly show any webpage in iframe without any problem. 

    I guess MS hastily introduced HTML5/Javascript option just to show their compatibility. Also, at this moment, there is no way to write Win phone 8 apps in javascript anyway. Even getting 3rd party libraries like JQuery work is also difficult. 

    Disclaimer: I am big fan of MS technologies for the last 14 years but the js implementation is very naive. 

    Thursday, August 23, 2012 3:59 AM
  • Hi, not being able to display the web content is putting HTML/Javascript app in serious disadvantage against c# ones.  I agree with Pierce1161. 

    Having the ability to display the web content will give us ability to implement many other features.  Right now, this issue is blocking a major feature for our app.  

    Let's imagine what we can do if we have this ability.  Eg. a news reader app is now able to display the news site on a panel on the right while the user scroll through different news item on the left.  

    This is especially important to Metro app.  If every time a user clicks on the link, he goes to a browser, then he may not come back to the app.  This is different from a website.  On a website, the link will merely go to another tab.  The user can easily come back to the site.  But for a Metro app, the user will go to another full screen browser.  And then they may not come back to the app.  

    Friday, December 14, 2012 1:11 AM