Features and restrictions by context (HTML)

[ This article is for Windows 8.x and Windows Phone 8.x developers writing Windows Runtime apps. If you’re developing for Windows 10, see the latest documentation ]

Learn about the features available to pages in the local and web contexts.

A Windows Runtime app using JavaScript contains at least one HTML page. That page, and any other pages you include in the app itself, generally run in the app's local context. When you use an iframe to navigate to a remote page, that page runs in the web context and has limited access to your system.

You can use the ApplicationContentUriRules section of the app's package manifest to give a page in the web context access to your system's geolocation devices (if your app has permission to access this functionality), as well as access to the clipboard.

General features and restrictions

This table describes some of the features and restrictions that are available depending on whether the page is running in the local or web context.

Feature	Local context	Web context
Windows Runtime	Yes	No
Windows Library for JavaScript	Yes	Yes* (See the Windows Library for JavaScript in the web context section for details.)
JavaScript URIs (attribute="javascript:code")	No A URI can refer to defined JavaScript functions (attribute="myFunction()"), but can't be a JavaScript statement ( attribute="javascript: 2 + 2;").	Yes
Data URIs ("data:" ) for fonts	No	Yes
External script references (<script src="http://*" /> )	No Script must come from locally packaged content.	Yes
window.close	Yes Important  While you can technically use window.close in a local context, we don't recommend it. It will generate an error and cause the Windows Store to reject the app.	No
Cross-domain XHR requests	Yes	No
Automatic toStaticHTML validation	Yes	No
Application Cache	Yes	Yes
Cross-domain XHR requests	Yes	No

 

Windows Library for JavaScript in the web context

Although you can use WinJS in the web context, some of its APIs work differently because the web context does not have access the Windows Runtime. Here are some of the APIs that are affected:

API	Behavior changes in the web context
WinJS.UI.AppBar	Does not automatically provide the correct default strings for the current culture. In the web context, the control displays en-us strings. Does not listen to Windows Runtime events.
WinJS.UI.ListView	Does not use user-customizable system metrics and animation settings. Intead, the control falls back to default WinJS settings.
WinJS.UI.Rating	Does not automatically provide the correct default strings for the current culture. In the web context, the control displays en-us strings.
WinJS.UI.SettingsFlyout	This control is not available in the web context.
WinJS.UI.StorageDataSource	This data source is not available in the web context.
WinJS.UI.ToggleSwitch	Does not automatically provide the correct default strings for the current culture. In the web context, the control displays en-us strings.
WinJS.UI.Tooltip	Does not use user-customizable system metrics and animation settings. Intead, the control falls back to default WinJS settings. Does not get the user's handedness. The control assumes the user is right-handed.