You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cordova.apache.org by "Brandon Paddock (JIRA)" <ji...@apache.org> on 2015/03/08 21:55:38 UTC
[jira] [Updated] (CB-8632) Plugin should use x-ms-webview and not
iframe on Windows 8.1+
[ https://issues.apache.org/jira/browse/CB-8632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brandon Paddock updated CB-8632:
--------------------------------
Description:
Currently, the InAppBrowser plug-in uses an iframe when running on Windows 8.1 and Windows Phone 8.1. This is severely limiting and causes things to fail which work fine on other platforms.
A key example is trying to host my own site's content in the app. Our server specifies X-Frame-Options: SAMEORIGIN in its HTTP response headers. This has no effect on normal WebView controls, which ignore this by design. However, the iframe that this plug-in uses respects it, giving this error:
APPHOST9613: The app couldn’t navigate to https://<ourtestsite> because of this error: FORBIDFRAMING.
Since Windows provides a native WebView control (which works inside WWAHost web apps and is accessible as the x-ms-webview HTML element type), the plug-in should be updated to use this when it's available.
There are other advantages to doing this versus the X-Frame-Options issue I mentioned (which I can perhaps do an annoying UA-based workaround for I suppose), such as:
1) Separate UI thread/process/AppContainer (depending on OS version).
2) Behaviors and API surface more tuned to WebView (and in-app browser) scenarios.
3) Customizable user agent, etc.
was:
Currently, the InAppBrowser plug-in uses an iframe when running on Windows 8.1 and Windows Phone 8.1. This is severely limiting and causes things to fail which work fine on other platforms.
A key example is trying to host my own site's content in the app. Our server specifies X-Frame-Options: SAMEORIGIN in its HTTP response headers. This has no effect on normal WebView controls, which ignore this by design. However, the iframe that this plug-in uses respects it, giving this error:
APPHOST9613: The app couldn’t navigate to https://devtest1.zealyst.com/Account/Login?ReturnUrl=%2F because of this error: FORBIDFRAMING.
Since Windows provides a native WebView control (which works inside WWAHost web apps and is accessible as the x-ms-webview HTML element type), the plug-in should be updated to use this when it's available.
There are other advantages to doing this versus the X-Frame-Options issue I mentioned (which I can perhaps do an annoying UA-based workaround for I suppose), such as:
1) Separate UI thread/process/AppContainer (depending on OS version).
2) Behaviors and API surface more tuned to WebView (and in-app browser) scenarios.
3) Customizable user agent, etc.
> Plugin should use x-ms-webview and not iframe on Windows 8.1+
> -------------------------------------------------------------
>
> Key: CB-8632
> URL: https://issues.apache.org/jira/browse/CB-8632
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin InAppBrowser
> Affects Versions: 3.5.0
> Environment: Windows 8.1, Windows Phone 8.1
> Reporter: Brandon Paddock
>
> Currently, the InAppBrowser plug-in uses an iframe when running on Windows 8.1 and Windows Phone 8.1. This is severely limiting and causes things to fail which work fine on other platforms.
> A key example is trying to host my own site's content in the app. Our server specifies X-Frame-Options: SAMEORIGIN in its HTTP response headers. This has no effect on normal WebView controls, which ignore this by design. However, the iframe that this plug-in uses respects it, giving this error:
> APPHOST9613: The app couldn’t navigate to https://<ourtestsite> because of this error: FORBIDFRAMING.
> Since Windows provides a native WebView control (which works inside WWAHost web apps and is accessible as the x-ms-webview HTML element type), the plug-in should be updated to use this when it's available.
> There are other advantages to doing this versus the X-Frame-Options issue I mentioned (which I can perhaps do an annoying UA-based workaround for I suppose), such as:
> 1) Separate UI thread/process/AppContainer (depending on OS version).
> 2) Behaviors and API surface more tuned to WebView (and in-app browser) scenarios.
> 3) Customizable user agent, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@cordova.apache.org
For additional commands, e-mail: issues-help@cordova.apache.org