Search Logger
Category: Microsoft News

Microsoft News

Sharing Links from IE10 on Windows 8

3:53 pm - May 14, 2012 in IEBlog

Sharing a link to a Web page is a common activity on the PC, and it gets better with IE10 on Windows 8. One of the new features on Windows 8 is the Share charm, which allows you to seamlessly send content between apps on your PC. Previously, if you wanted to share an interesting article with your friend, or post a funny picture on your blog, you’d copy the link from the address bar, switch to a different site or app, and then paste it. Now, with the Windows 8 Share charm, you can share directly from the browser without ever leaving your current page.

When you use the Share charm to share a site from the browser, IE10 creates two data formats that contain relevant content – the URI, and some HTML that includes a rich representation of the page. Here are two examples of data that get shared for a YouTube video:

The URI (of the current site)

http://www.youtube.com/watch?v=4DbgiOCTQts

The HTML (with a link preview)

An example of IE10's rich preview of Web pages
An example of IE10's rich preview of Web pages

Both of these data formats are created for an “implicit” share, which is the name for what happens when you share the site that you are currently viewing. Since Web pages can be represented as hyperlinks or a rich HTML link preview, IE10 includes both types of data. Of course, if you aren’t sharing the whole page, but rather, some content that you’ve highlighted, IE10 will share the HTML of your selection instead of the URI and the link preview. In this case, sharing a selection would be called an “explicit” share, and does not include the link. This post describes the link sharing case, how IE10 participates in the Windows 8 Share contract using HTML, and how Web developers can create link previews with just a few meta-tags.

The Share Charm and IE10

Here’s a video of how a user might share links from the browser to an app that uses HTML.


Sharing from IE10: Link Previews in Action

In this video, “Stash” is a sample link saving app that makes use of the Windows share charm with HTML. The sample app simply supports the HTML data format for sharing, and IE provides the link preview. Link previews are HTML that contains a title, image, and description for every shared link. This makes it easy for you to recognize the site content. If you have Windows 8 Consumer Preview and Visual Studio 11 Beta, you can download and run Stash on your own PC. Stash integrates with the Windows 8 Share contract as a target app, as you can see below. Below, you can see a high-level diagram that shows how links are shared from IE10.

Diagram showing sharing a link from IE10 to target apps, using the Share charm’s data package
Diagram: Sharing a link from IE10 to target apps, using the Share charm’s data package

Windows 8 Share charm handles the coordination between the source and target apps to provide an integrated sharing experience across all apps. This removes the need for target and source apps to be aware and coordinate between each other.

Sharing the Web is Better, Start to Finish

The Web is made up of HTML. That’s why HTML is one of the most important data formats in IE10’s integration with the Share contract. IE10 creates link previews to both provide a better sharing experience for users, and to help connect Web developers to Windows 8 Share. With a little extra meta-data markup, sites can define what information is included in their link previews. On the other end of the share contract, target apps that support the HTML data format can get the full experience of contextual Web hyperlinks without having to parse a single site. The end result is a rich, modern, and fluid sharing experience, from end to end.

Screenshot of target apps available in Share pane
Screenshot of target apps available in Share pane

Screenshot of Stash’s Share Pane
Screenshot of Stash’s Share Pane

When you share a Web site, IE10 parses that site to create a link preview. In the example above, it’s a short snippet of content that represents a movie page on IMDb. The goal of sharing HTML, in addition to the URI, is to share the best possible representation of what the user intended to share, so IE10 creates link previews for all implicit shares. The benefits of HTML are that it can include more information than a URI, and the content of the HTML is more meaningful than a hyperlink. In the words of Leslie Knope, no one wants to share that “complicated nonsense.”

Frame grab from the NBC show Parks and Recreation. Character Ron Swanson is holding a Knope for City Council sign most of which is long, complicated URL. Character Leslie Knope is saying, "So, as you can imagine, we would have never ordered a sign with all this complicated nonsense because, you know, we’re not insane."
From NBC’s Parks and Recreation, Season 4, Episode 16

So, as you can imagine, we would have never ordered a sign with all this complicated nonsense because, you know, we’re not insane.

Depending on the target app, though, sometimes rich content is not the best kind of data, and a URI is more useful. For example, blogging apps can take advantage of rich HTML content, and SMS apps would do best to use the URI. Developers of Metro style apps choose the data format(s) that make most sense for their app to receive, following the Windows 8 Share guidance.

Sites Use Markup to Define What IE10 Shares

Since IE10 uses existing markup meant for sharing on the Web, many sites will already look great when sharing HTML link previews on Windows 8. We support the Open Graph protocol as a simple way to add meta-data about the page. When users share sites on Facebook and through Windows 8 and IE10, you can use OpenGraph to control the way your Web page appears to others.

Here’s an example of an IE test drive demo that uses this markup:

<head>

<meta name="description" content="Brick Breaker TestDrive Demo Game, Performance and Touch benchmark" />

<title>Brick Breaker</title>

<meta property="og:image" content="Views/Homepage/Icons/BrickBreaker.png" />

</head>

IE looks for the following tags in the site’s markup to create the page’s link preview.

Property HTML tag Character limit
Title 1 <meta name="title" content="Insert Site Title Here” /> 160
Title 2 <title>Insert Site Title Here</title> 160
Description <meta name="description" content="Insert Site Description Here” /> 253
Image 1 <meta property="og:image" content="insert_image_link_here" /> 2,048 (limit for image URI)
Image 2 <link rel="image_src" href="insert_image_link_here" /> 2,048 (limit for image URI)
Image 3 <meta name="image" content="insert_image_link_here" /> 2,048 (limit for image URI)
Image 4 <meta name="thumbnail" content="insert_image_link_here" /> 2,048 (limit for image URI)

Note that this is the order in which we parse for each attribute. For example, if both Image 1 and Image 2 tags are present, we’ll use the Image 1 tag. Additionally, if more than one tag of any type is present, we use the first one you list in your markup.

For character limits, if the description is longer than the maximum length, IE will put a “…” at the end in the preview.

Make sure to include at least one of each property in your site markup to get your pages looking great for sharing in Windows 8. See this demo on the IE Test Drive site for more on how the markup works.

Apps Get the Benefit of a Powerful Web Browser

If your app supports the Share target app contract, you should consider whether it makes sense for it to support HTML as a shared data format. Apps that use HTML can benefit from the link previews shared by IE10 because IE10 does all of the heavy lifting. It parses the site and puts together a short and informative link preview, and all your app needs to do is display and host the HTML. The hyperlink is embedded within the preview, so it functions just like a Uri, but looks much better. This way, apps that don’t have the resources to parse the Web to condense pages into small, rich previews, can still display contextual links as HTML.

Many apps, in addition to IE10, will share HTML. Target apps that accept HTML must be agnostic about the source of the shared data. As noted above, IE10 shares HTML for both implicit and explicit sharing scenarios, so sometimes the HTML is a link preview, and sometimes it’s a user selection. In either case, the content of the HTML is the best possible representation of what the user intended to share. Here’s a snippet of what the link preview HTML generated by IE10 will look like when it’s added to the Share charm’s Data Package:

<html>

<body>

<!--StartFragment-->

<style>

/* IE10\uc1\u8217?s metro-style CSS attributes */

</style>

<a class="snippet-URL" href="http://site_link_goes_here">Website Title goes here</a>

<table>

<tr>

<td class="snippet-image">

<img src="image_link_goes_here" />

</td>

<td class="snippet-text">Website description goes here </td>

</tr>

</table>

<!--EndFragment-->

</body>

</html>

For an example of an app that uses HTML from IE10, download the sample app “Stash” seen in the video above. This app demonstrates how a Metro style app can use HTML data as a share target.

Here’s a code snippet from the app, which shows how Stash uses HTML sent from the Share charm.

function activatedHandler(eventArgs) {

// In this sample we only do something if it was activated with the Share contract

if (eventArgs.detail.kind

=== Windows.ApplicationModel.Activation.ActivationKind.shareTarget) {

// We receive the ShareOperation object as part of the eventArgs

var shareOperation = eventArgs.detail.shareOperation;

if (shareOperation.data.contains(

Windows.ApplicationModel.DataTransfer.StandardDataFormats.html)) {

shareOperation.data.getHtmlFormatAsync().then(

function (htmlFormat) {

// Extract the HTML fragment from the HTML format

var htmlFragment = Windows.ApplicationModel.DataTransfer

.HtmlFormatHelper.getStaticFragment(htmlFormat);

// Display the HTML in the Share pane.

id("htmlArea").innerHTML = htmlFragment;

});

}

}

}

The above code lets Stash accept HTML when the user selects it as their Share target. For more on developing a Share target app on Windows 8, see the MSDN Quickstart page for receiving shared content.

Happy sharing!

—Alex Feldman, Program Manager, Internet Explorer

 

Diagnosing JavaScript Errors Faster with Error.stack

4:54 pm - May 10, 2012 in IEBlog

IE10 in Windows 8 Consumer Preview includes support for Error.stack, which enables Web developers to diagnose and correct bugs faster, especially those that are difficult to reproduce. Developers can build amazing apps with the capabilities of Web platforms that power today’s modern browsers. In Windows 8, we expose that power through both Internet Explorer 10 and Metro style apps in JavaScript. The increasing power and complexity of these apps means developers need better tools like Error.stack for handling errors and diagnosing bugs.

Debugging Applications

Structured error handling in JavaScript rests on throw and try/catch – where the developer declares an error and passes the control flow to a portion of the program that deals with error handling. When an error is thrown, Chakra, the JavaScript engine in Internet Explorer, captures the chain of calls that led up to where the error originated – also referred to as the call stack. If the object being thrown is an Error (or is a function whose prototype chain leads back to Error), Chakra creates a stack trace, a human-readable listing of the call stack. This listing is represented as a property, stack, on the Error object. The stack includes the error message, function names, and source file location information of the functions. This information can help developers rapidly diagnose defects by learning what function was being called, and even see what line of code was at fault. For example, it might indicate that a parameter passed into the function was null or an invalid type.

Let’s explore with an example of a simple script that attempts to calculate the distance between two points, (0, 2) and (12, 10):

(function () {

'use strict';

function squareRoot(n) {

if (n < 0)

throw new Error('Cannot take square root of negative number.');

 

return Math.sqrt(n);

}

 

function square(n) {

return n * n;

}

 

function pointDistance(pt1, pt2) {

return squareRoot((pt1.x - pt2.x) + (pt1.y - pt2.y));

}

 

function sample() {

var pt1 = { x: 0, y: 2 };

var pt2 = { x: 12, y: 10 };

 

console.log('Distance is: ' + pointDistance(pt1, pt2));

}

 

try {

sample();

}

catch (e) {

console.log(e.stack);

}

})();

This script has a bug – it forgets to square the differences of the components. As a result, for some inputs, the pointDistance function will simply return incorrect results; other times, it will cause an error. To understand the stack trace, let’s examine the error in the F12 developer tools and look at its Script tab:

Screen shot of the F12 developer tools showing a stack trace logged by calling console.log(e.stack) where e is the Error object passed to the catch clause of a try/catch block.

The stack trace is dumped to the console in the catch clause, and because it’s at the top of the stack, it’s readily apparent that the Error is originating in the squareRoot function. To debug the problem, a developer wouldn’t have to go very deep into the stack trace; squareRoot’s precondition was violated, and looking one level up the stack, it’s clear why: the sub-expressions within the call to squareRoot should themselves be parameters to square.

While debugging, the stack property can help identify code for setting a breakpoint. Bear in mind that there are other ways to view the call stack: for instance, if you set the script debugger to “Break on caught exception” mode, you may be able to inspect the call stack with the debugger. For deployed applications, you may consider wrapping problematic code within try/catch in order to capture failed calls, and log them to your server. Developers would then be able to look at the call stack to help isolate problem areas.

DOM Exceptions and Error.stack

I noted previously that the object being thrown must be an Error or lead back to Error via its prototype chain. This is intentional; JavaScript supports throwing any object and even primitives as exceptions. While all of these can be caught and examined, they are not all specifically designed to contain error or diagnostic information. As a consequence, only Errors will be updated with a stack property when thrown.

Even though DOM Exceptions are objects, they don’t have prototype chains that lead back to Error, and therefore they don’t have a stack property. In scenarios in which you are performing DOM manipulation and want to surface JavaScript-compatible errors, you may want to wrap your DOM manipulation code within a try/catch block, and throw a new Error object within the catch clause:

function causesDomError() {

try {

var div = document.createElement('div');

div.appendChild(div);

} catch (e) {

throw new Error(e.toString());

}

}

However, you will probably want to consider whether you want to use this pattern. It is likely best-suited for utility library development; specifically, consider whether your code’s intent is to hide DOM manipulation, or to simply carry out a task. If it is hiding DOM manipulation, wrapping the manipulation and throwing an Error is probably the right way to go.

Performance Considerations

The construction of the stack trace begins when the error object is thrown; doing so requires walking the current execution stack. To prevent performance problems in traversing a particularly large stack (possibly even a recursive stack chain), by default, IE only collects the top 10 stack frames. This setting is configurable, however, by setting the static property Error.stackTraceLimit to another value. This setting is global, and must be changed prior to throwing the error, or else it will not have an effect on stack traces.

Asynchronous Exceptions

When a stack trace is generated from an asynchronous callback (for example, a timeout, interval, or XMLHttpRequest), the asynchronous callback, rather than the code that created the asynchronous callback, will be at the bottom of the call stack. This has some potential implications for tracking down offending code: if you use the same callback function for multiple asynchronous callbacks, you may find it difficult to determine by inspection alone which callback caused the error. Let’s slightly modify our previous sample so that, instead of calling sample() directly, we’ll put that into a timeout callback:

(function () {

'use strict';

function squareRoot(n) {

if (n < 0)

throw new Error('Cannot take square root of negative number.');

 

return Math.sqrt(n);

}

 

function square(n) {

return n * n;

}

 

function pointDistance(pt1, pt2) {

return squareRoot((pt1.x - pt2.x) + (pt1.y - pt2.y));

}

 

function sample() {

var pt1 = { x: 0, y: 2 };

var pt2 = { x: 12, y: 10 };

 

console.log('Distance is: ' + pointDistance(pt1, pt2));

}

 

setTimeout(function () {

try {

sample();

}

catch (e) {

console.log(e.stack);

}

}, 2500);

})();

Upon executing this snippet, you’ll see the stack trace come up after a slight delay. This time, you’ll also see that the bottom of the stack is not Global Code but rather is Anonymous function. In fact, it’s not the same anonymous function, but the callback function passed into setTimeout. Since you lose the context surrounding hooking up the callback, you may not be able to determine what is causing the callback to be called. If you consider a scenario in which one callback is registered to handle the click event of many different buttons, you will be unable to tell to which callback the registration refers to. That being said, this limitation is only minor, because, in most cases, the top of the stack will likely highlight the problem areas.

Exploring the Test Drive Demo

Screen shot of Test Drive demo Explore Error.stack

Check out this Test Drive demo using IE10 in the Windows 8 Consumer Preview. You can execute code in the context of an eval and if an error occurs, you’ll be able to inspect it. If you’re running the code within IE10, you’ll also be able to highlight the lines of your code as you hover over the error lines in the stack trace. You can type code into the Code area yourself, or select from several samples in the list. You can also set the Error.stackTraceLimit value when running the code samples.

For reference material, you may want to cruise over to the MSDN documentation for Error.stack as well as stackTraceLimit.

—Rob Paveza, Program Manager, Chakra Runtime

 

Building cross-browser plugin-free experiences

5:04 pm - April 26, 2012 in IEBlog

We've talked about how the transition to a plug-in free Web is happening today. Lots of Web browsing happens on devices that simply don’t support plug-ins. Web sites that use plug-ins need to understand what their customers experience when browsing plug-in free. In case you missed it, check out Rey Bango’s blog post where he lays out clear guidance for developers on building cross-browser plugin-free experiences and addressing issues like cross-browser CSS, media playback, and touch.

-- John Hrvatin, Program Manager Lead, Internet Explorer

 

Guidelines for Building Touch-friendly Sites

1:14 pm - April 20, 2012 in IEBlog

In Windows 8 Consumer Preview, IE10 enables fast and fluid multi-touch experiences on the Web. Most sites work fine with touch in IE10 with no changes to the site. This post provides four simple guidelines to ensure your customers who use touch can most effectively use your site.

We’ve written before about how new input devices and touch screens make the Web more fun, interactive, and immersive. We’ve also talked about the importance of ensuring a no compromise browsing experience in IE10 so the real Web works great with touch.

Of the four guidelines below, the first two make sure touch users can access all of your site’s functionality. The last two provide tips to make your site easier to use with touch.

DO NOT Hide Content Behind Hover

A mouse can hover content (point at it) without activating it (clicking it). However, with touch a tap is both hover and activation in one action. So functionality that requires hover without activating will not work for touch users. Instead, consider making all behaviors click (tap) based.

    DO Configure the Browser for the Default Touch Behaviors That Work Well For Your Site

    Users expect to be able to pan and zoom sites using touch. Therefore, the browser consumes touch moves, pinches, and double-taps by default and does not send events for these interactions. If your site needs to provide special functionality for these interactions instead, you must configure IE10 to provide only the default behavior you want, if any.

    When a user touches an element, the -ms-touch-action CSS property determines the default behavior that IE10 provides.

    -ms-touch-action: auto | none | manipulation | double-tap-zoom | inherit;

    The table below describes the five possible values.

    ValueDescription
    auto The browser determines the behavior for the element.  This is the default value for -ms-touch-action.
    none No default behavior is allowed.
    manipulation Only panning, pinch zoom, and swiping to navigate forward or back are allowed.
    double-tap-zoom Only double-tap zooming is allowed.
    inherit The element inherits the value of -ms-touch-action from its parent.

    For example, a canvas painting application might use:

    canvas {

    -ms-touch-action: double-tap-zoom;

    }

    With this configuration, the user can double-tap to zoom in to the canvas element, but sliding a finger on the canvas element will send events to it rather than pan the page.

    DO Identify Input Types Using HTML5 Forms

    IE10 introduces support for HTML5 input controls, all of which are touch optimized. For text inputs, you can further improve your users’ touch experiences by identifying the specific input type, when applicable. Internet Explorer will show a tailored touch keyboard layout for that input type on Windows 8:

    <input type="email">

    The touch keyboard shows @ and “.com” buttons for email addresses.
    The touch keyboard shows @ and “.com” buttons for email addresses.

    <input type="tel">

    The touch keyboard shows a number pad for telephone numbers.
    The touch keyboard shows a number pad for telephone numbers.

    <input type="url">

    The touch keyboard shows forward slash and “.com” for URLs.
    The touch keyboard shows forward slash and “.com” for URLs.

    Diagram showing relative finger widths and an average finger width of 11 mmDO Provide Ample Room for Users’ Fingers

    To build Windows 8’s touch-first experience, we’ve done a ton of research to formulate some helpful guidelines for developers. The average width of a finger is 11mm. As targets for tapping get larger, the percentage of accidental missed taps drops off quickly.

    Ideally, a target is at least 11mm (about 40px) square with at least 2mm (about 10px) of padding around it.

    40px or more target size
    10px or more between targets

    If you want to adjust the spacing only for users with touch hardware, use feature detection.

    To detect that user has touch hardware:

    if (navigator.msMaxTouchPoints && navigator.msMaxTouchPoints > 1) {

    // Supports multi-touch

    }

    Going Beyond These Basics

    You can do much more to create a great touch-first experience. For example, you may choose to optimize for touch by supporting custom multi-touch interactions or gestures. Here are a few links to get you started:

    We plan to write more about these methods in future blog posts. Applying these guidelines today will ensure your sites work well with touch in IE10.

    — Jacob Rossi, Program Manager, Internet Explorer

     

    IE 9.0.6 Available via Windows Update

    4:28 pm - April 10, 2012 in IEBlog

    The April 2012 Cumulative Security Update for Internet Explorer is now available via Windows Update. This security update resolves five privately reported vulnerabilities in Internet Explorer. The most severe vulnerabilities could allow remote code execution if a user visits a specially crafted Web page using Internet Explorer. An attacker who successfully exploited any of these vulnerabilities could gain the same user rights as the local user. Users whose accounts are configured to have fewer user rights on the system could be less affected than users who operate with administrative user rights.

    This security update is rated Critical for Internet Explorer 6, Internet Explorer 7, Internet Explorer 8, and Internet Explorer 9 on Windows clients and Moderate for Internet Explorer 6, Internet Explorer 7, Internet Explorer 8, and Internet Explorer 9 on Windows servers. For more information, see the full bulletin.

    Most customers have enabled automatic updating and do not need to take any action. We recommend that customers, who have not enabled automatic updating, enable it (Start Menu, type “Windows Update”). We recommend that administrators, enterprise installations, and end users who want to install this security update manually, apply the update immediately using update management software or by checking for updates using the Microsoft Update service.

    —Tyson Storey, Program Manager, Internet Explorer

     

    Pinned Sites in Windows 8

    3:42 pm - April 3, 2012 in IEBlog

    The Windows 8 Start screen is the best place to find and stay connected to all your favorite apps and content. App tiles are alive with activity and show you fresh and tailored content so you know what’s new in your world.

    We’ve written about Internet Explorer 10’s Metro style browsing experience on Windows 8. This post describes in detail IE10’s pinned sites and their availability on the Windows 8 Start screen—complete with site-centric visuals and badge notifications to let you know there is new content. We’ll also walk through the Web developer details to support pinned sites.

    The following video shows pinned sites in action on Windows 8 Consumer Preview.


    Pinned Sites in Windows 8

    Pinned Sites – More than Favorites

    Consumers on Windows spend most of their time on the Web and we know from Windows opt-in telemetry (officially, the Microsoft Customer Experience Improvement Program), that they go back to the same set of sites time and again. Pinned sites on Windows 8 make it fast and easy to immediately get to your sites. With badge notifications, site tiles come alive with up-to-date information and help you know when new content is available.

    Developers can utilize pinned sites to better connect their site with their users and promote their site’s brand directly in the Windows start screen. We found that sites that used this feature with IE9 on Windows 7 see anywhere from a 15 percent to 50 percent increase in site visits. In Windows 8 the experience for consumers is even better with site tile updates, even when you don’t have the site open in the browser.

    The following two screen shots illustrate pinned site tiles and badge notifications.

    Pinned sites on the Start screen showing site-centric visuals and badge notifications
    Pinned sites on the Start screen showing site-centric visuals and badge notifications

    Example of a badge notification on a pinned site’s tile
    Example of a badge notification on a pinned site’s tile

    Site-Centric Visual on the Pinned Site Tile

    As a Web developer, you can provide a site icon (favicon) that IE10 uses throughout the browser to represent the site, in the address bar, on the new tab page, and on the Start screen. IE10 uses the large site icon (32 x 32 pixels) to identify the site when pinned to the Start screen the same way that IE9 used it for pinning to the task bar.

    Screen shot of pinning a site with Metro style IE10 showing a preview of the site’s tile
    Screen shot of pinning a site with Metro style IE10 showing a preview of the site’s tile

    IE10 extracts the dominant color from the icon and automatically uses it as the background color for the Start screen tile.

    One tool for creating icons is x-icon editor. Use it to create the 32x32 icon for your site. It can also convert an image to the icon file format (.ico). Then associate the .ico using traditional favicon markup:

    <link href="testdrive.ico" rel="shortcut icon" />

    Badge Notifications That Update In the Background

    Windows 8 can poll for updates for pinned tiles on the Start screen. This works well for lightweight notifications such as new messages from other users (email & social networking), new discounts on a shopping site, new articles on a newsfeed etc.

    With Internet Explorer 10 and Windows 8, you can offer badge notifications directly on your pinned site tiles. This means users get updates to their sites without the site being open in the browser. As an example, pin the Fresh Tweets demo using IE10 on Windows 8 Consumer Preview. The pinned site tile updates on a regular basis and notifies the user when there are new tweets available.

    Background notifications require site-provided components. These are: (1) Badge Notification XML, an XML response that describes the badge notification for Windows, and (2) Pinned Site Meta Tags, Web page markup that points to the location which Windows should poll for notifications and the frequency of polling.

    Badge Notification XML

    Windows handles the polling and drawing of badge notifications. Windows polls the badge notification XML that describes the visual for the pinned site tile. The badge XML schema defines this simple XML response. For example, to update the tile with the number “3,” you send the following XML:

    <?xml version="1.0" encoding="utf-8" ?>

    <badge value="3"/>

    Badges can be numbers or glyphs, such as ‘alert’ and ‘new message’ indicators. For a full list of what a badge can display, see Choosing a badge image on MSDN.

    Pinned Site Meta Tags

    The next step is associating the badge notification XML to the Web page. IE10 uses the meta tag “application-name” to determine if the Web page supports pinned sites capabilities like notifications and jump lists. To support badge notifications, include a new meta-tag in your markup with the URL of the badge notification XML and the frequency with which Windows should request it. IE checks to see if the “msApplication-badge” meta tag is present on the page at time of pinning, as well as on subsequent launches of the site from the pinned site tile.

    <meta name="msapplication-badge" value="frequency=360;polling-uri=http://ietestdrive2.com/PinnedSites/TweetCounter/microsoft/360" />

    The value parameter has two parts: polling-uri (required) and frequency (optional).

    polling-uri is the absolute URI from which Windows requests the simple XML document defined above.

    frequency is an optional number of minutes between updates and must be one of the following values:

    • 30 (Windows will poll the URI every 30 minutes)
    • 60 (1 hour)
    • 360 (6 hours)
    • 720 (12 hours)
    • 1440 (1 day. This is the default.)

    If frequency is omitted or has a value other than one listed above, it defaults to daily updates (1440 minutes).

    Developer APIs for updating Badge Notifications

    You can also clear and refresh the site tile badge from the Web page directly to ensure that the site tile is up-to-date.

    When a user launches the pinned site tile through the Start screen, the Web site is running in its own session called SiteMode and can use the following JavaScript functions to update the badge.

    window.external.msSiteModeClearBadge() clears the badge notification on the tile. In the Fresh Tweets demo, when the user receives a notification and taps on the tile to launch the browser, the Web page uses msSiteModeClearBadge() to clear the notification from the tile. The next time the tile lights up with a badge update, the user knows there is new content.

    window.external.msSiteModeRefreshBadge() calls Windows to update the badge on the site using the polling URI. As an example, the user sees a pinned site tile indicating three unread messages and clicks on the tile to return to the site. If he or she reads only the first update, you can trigger an update so the badge reflects the correct read/unread count of two.

    In Windows 8 Consumer Preview, these two APIs only function on sites running in the Local intranet or Trusted sites zones. This will be fixed in the next preview. To test these APIs in the Consumer Preview on your own site, add its domain to the Trusted sites list using the Security tab of the Internet Properties dialog.

    Desktop Taskbar Notifications

    Notifications that appear as icon overlays for pinned sites on the desktop taskbar will continue to work for Windows 8 and IE10 on the desktop. This form of notification is not available on the pinned site for the Windows 8 Start screen. Windows 8 handles notifications for all tiles on the Start screen and does so in a battery-efficient way.

    Jump Lists to Quickly Navigate Within the Site

    Many top sites such as NYTimes.com, CNN.com, and Amazon.com support IE9 pinned sites features such as jump lists to get to a specific task or part of a site. With IE10, jump lists are available as part of the navigation bar for a touch-friendly way to navigate the site.

    When the user launches the site from the Start screen, the pin button shows that there are jump lists available for this site:

    Screen shot showing the Fresh Tweets Demo’s jump list
    Screen shot showing the Fresh Tweets Demo’s jump list

    The jump list displayed is the same as IE9 displays on the Windows 7 taskbar.

    You can add static tasks to your site’s jump list via page markup (learn more) or dynamically based on user interactions (learn more). Badge and jump lists in Windows 8 are a site-centric feature. Each fully qualified domain name can have one and only one set of polling data and jump list data.

    Conclusion

    Internet Explorer 10 puts sites at the center of the experience through integration with the Windows 8 Start screen. Web developers can create site-centric visuals for pinned site tiles, share when there are new updates available for the site, and offer jump lists to navigate quickly around the site.

    We look forward to you adding these simple features to your Web site to maximize their impact in Windows 8.

    —Rahul Lalmalani, Program Manager, Internet Explorer

     

    Launch Options for Internet Explorer 10 on Windows 8

    11:24 am - March 26, 2012 in IEBlog

    IE10 is a new browsing experience built in lockstep with Windows 8 to give you all the advantages that Metro style applications offer. We built that experience by extending IE’s underlying architecture to provide a fast, fully hardware accelerated browsing engine with strong security and support for HTML5 and other Web standards. IE10 also includes a desktop experience for when you are using desktop tools and wish to continue using them in your existing workflows.

    Following last September’s release of the Windows 8 Developer Preview, we heard a lot about giving you the option to control which experience of Internet Explorer—Metro style or on the desktop —to launch when clicking a link in another application. In the Windows Consumer Preview, IE10 offers you that control.

    By default, Windows 8 Consumer Preview opens links using the flavor of Internet Explorer that matches your current environment: if you’re running a Metro style application, following a link launches Metro style IE10; if you’re running a desktop application, following a link launches IE10 on the desktop. You can override this default behavior using the Programs tab of the Internet Properties dialog.

    Screen shot of the Programs tab of the Windows 8 Internet Properties dialog showing the option for choosing how Internet Explorer opens links.

    You can locate these settings quickly by using the Start screen’s search capability and searching for terms such as “links,” “launch,” or “open links.” Show below is the result of search for the term “launch.”

    Screen shot of a Settings section of the Windows 8 Start search results page when "launch" is searched for. "Choose how you open Internet Explorer" is selected in the search results.

    The following sections describe the available settings.

    Opening Links

    The first setting of the Browser Launch Settings (labeled “Choose how you open links”) controls what happens when you click a link in another program. Your choices include:

    Options for Opening Links Behavior
    Let Internet Explorer decide Launch links based on the environment you are in
    Always in Internet Explorer Launch links in the Windows 8 (Metro style) environment
    Always in Internet Explorer on the desktop Launch links in the desktop environment

    The default for this setting is “Let Internet Explorer decide.” In other words, links will launch into the appropriate experience based on the invoking context—desktop or Metro style. Links will open in the desktop IE10 when a link is clicked from a desktop application, for example, Microsoft Word, and in Metro style IE10 when a link is opened from a Metro style application.

    Opening Internet Explorer from the Start Screen

    In addition to controlling how Windows opens links, the Browser Launch Settings also provide users with options on how Internet Explorer application tiles launch from the Start screen. Internet Explorer’s application tile is the default launching point for the browser on the Start screen. You create pinned site tiles when you pin sites to the Start screen. The setting “Open Internet Explorer tiles on the desktop” controls what happens when you click the Internet Explorer or pinned site tile.

    Options for opening Internet Explorer Tiles Expected behavior
    (unchecked) Launch in the Windows 8 (Metro style) environment
    (checked) Launch in the desktop environment

    Launch Options and Browser Defaults

    IE10 is available in both Metro style and desktop experiences when it is the default browser. If Internet Explorer is not your default browser, only desktop IE is available and you cannot change IE’s Browser Launch Settings. The “Choose how you open links” option on the Programs tab of the Internet Properties dialog will be disabled (“grayed out”) when IE is not the default browser:

    Screen shot of the Programs tab of the Windows 8 Internet Properties dialog showing the option for choosing how Internet Explorer opens links disabled because IE10 is not the default browser.

    To change the default browser, type “default” on the Windows 8 Start screen. The Start screen will search apps, settings, and files for this term. The Apps results will include Default Programs. Touch or click it to bring up the Default Programs control panel item. From its list of options, select “Set your default programs” to display a page containing a list of programs on the left.

    Screen shot of the Set Default Programs control panel item showing "Internet Explorer" selected in the list of programs and "Set this program as default" being selected.

    Select “Internet Explorer” and then click or touch “Set this program as default.” This will set IE10 as the default browser on Windows 8 and enable its Metro style experience.

    Conclusion

    IE10 offers you a full-screen, immersive site experience. We’ve found that many people – even those with the most enthusiastic and intense browsing patterns – prefer Metro style browsing because it’s less manual and more focused on what you browse than on how you browse. That said, for some browsing, IE on the desktop continues to play an important role. The Browser Launch Settings allow you to change the default settings for a “no compromises” experience.

    Try out these settings, and let us know what you think. We look forward to your feedback here and on Connect.

    —Kevin Luu, Program Manager, Internet Explorer

     

    Speed and Mobility: An Approach for HTTP 2.0 to Make Mobile Apps and the Web Faster

    11:02 pm - March 25, 2012 in IEBlog

    This week begins face to face meetings at the IETF on how to approach HTTP 2.0 and improve the Internet. How the industry moves forward together on the next version of HTTP – how every application and service on the Web communicates today – can have a positive impact on user experience, operational and environmental costs, and even the battery life of the devices you carry around.

    As part of this discussion of HTTP 2.0, Microsoft will submit to the IETF a proposal for “HTTP Speed+Mobility.”  The approach we propose focuses on Web performance improvements at the same time it takes into account the important needs of mobile devices and applications.

    You can read more here about this proposal and an approach to HTTP 2.0 which considers network speed, cost, and device battery life, and works for everyone from sites owners, content providers, to consumers.

    -- Rob Mauceri, Group Program Manager, Internet Explorer

     

    IndexedDB Updates for IE10 and Metro style apps

    3:12 pm - March 21, 2012 in IEBlog

    The Internet Explorer team along with the broader Web community has continued to make improvements to the IndexedDB specification. IndexedDB is a W3C Working Draft that enables you to store, search, and retrieve data on the user's device, even when Internet connectivity is disabled.  IndexedDB is a feature of the Web platform shared by IE10 and Metro style apps in the Windows 8 Consumer Preview.

    This blog post describes changes we made in Internet Explorer 10 Consumer preview to implement the latest version of the W3C spec.

    Changes to Versioning

    The most significant change involves how developers update their database schemas (i.e. object stores, indexes) from one version to the next. The working group (including Microsoft) decided to replace the IDBDatabase.setVersion API with a new IDBFactory.open API. The new open API uses an additional parameter to detect if you want to use the current database version of the or if you want to update the database schema to a newer version. The open API now returns an IDBOpenDBRequest object which lets you register for the onupgradeneeded event. In the event handler you can update your database schema by adding additional object stores and indexes.

    To update your existing code, add a version parameter to your open method, replacing the call to setVersion, and register a new onupgradeneeded event handler on the IDBOpenDBRequest (see below).

    Old code example – green highlights the impacted code

    function openDBTest(dbName) {

    var rq = window.msIndexedDB.open(dbName);

    rq.onsuccess = successOpenningDB;

    rq.onerror = failureHandler;

    }

     

    function successOpenningDB(evt) {

    var db = evt.target.result;

    var rq = db.setVersion("1");

    rq.onsuccess = successHandler;

    rq.onerror = failureHandler;

    }

     

    function successHandler(evt) {

    //create schema

    }

    New code example – yellow highlights the changed code

    function openDBTest(dbName) {

    var rq = window.msIndexedDB.open(dbName, 1);

    rq.onsuccess = useDB;

    rq.onupgradeneeded = successHandler;

    rq.onerror = failureHandler;

    }

     

    function successHandler(evt) {

    //create schema

    }

    Additional Changes

    In addition, we made several smaller (but still significant) changes to the platform:

    • Added the IDBCursor.advance(count) method. This method enables you to skip records in a cursor, which in turn enables pagination scenarios. The count parameter defines the number of records you want to skip before accessing data. Valid values are 1 or greater.
    • Added the IDBObjectStore.count(key) and IDBIndex.count(key) methods. These enable you to count the records that match specific criteria. If the key value is not specified, a count of all records inside the index or the object store is returned.
    • Added the IDBFactory.cmp(first, second) method. This method compares two key values to determine if one value is greater than the other or both values are equal.
    • IDBKeyRanges now work with additional methods, including IDBObjectStore.count, IDBObjectStore.delete, IDBIndex.count. This allows you to match records that span groups of key values.
    • Values being added to the database needed no longer need to satisfy all previously defined indexes. This allows you to add records to an IDBObjectStore that fall outside the limits of previously defined indexes.
    • If an exception is thrown within the context of an active transaction, the transaction is aborted. This implies that if an exception is thrown within the onsuccess event handler of any request, the active transaction will be aborted. However, handling the exception will allow the database transaction to continue as normal.

      // This won’t abort the transaction because there is no active transaction.

      function createTransaction() {

      var txn = db.transaction("test");

      window.aaaaaa();

      }

       

      // This will abort the transaction because the exception is thrown when there is an active transaction.

      var rq = objectStore.add(record);

      rq.onsuccess = function (event) {

      window.aaaaaa();

      }

    • Added support to index properties on a Blob. This allows you to download binary data from the Web, store it locally, and use blob properties (e.g. name, size, etc.) as indexes or unique keys into the blob. This functionality enables scenarios like offline listening of your music collection or viewing of images and videos, while having the ability to search through your collection using the blob’s name. Our latest IE Test drive demo shows you how you can use this functionality to view your Facebook albums offline.
    • Screen shot of the IE Test Drive demo Facebook Companion
      Screen shot of IE Test Drive demo Facebook Companion

    We also submitted over 100 test cases to the W3C working group for IndexedDB, including new tests and updates to existing tests.

    Controlling How Sites and Apps use IndexedDB

    In addition to updates to match changes in the W3C specification, the Windows 8 Consumer Preview includes improvements that allow users to remain in control of how sites and apps use IndexedDB on their devices:

    • Introduced an uninstall handler for Metro style apps that use indexedDB. This handler ensures that any time end-users remove an application, the related data in the app’s IndexedDB database will be automatically deleted during the uninstall process.
    • Implemented a quotas (storage limits) to prevent sites from exhausting disk space. Quota limits can be updated by IT Admins via group policy settings or by users with administrative access to the Registry. However, quotas don’t apply to Metro style apps.
    • Added a new browser interface for end-users to manage their databases and manage quotas. Users can use the Caches and databases dialog to remove individual databases. Alternatively, you can remove all databases using the Delete Browsing History dialog to select the “Cookies and Web site data” checkbox.

    Screen shot of the new Caches and databases tab of the Website Data Settings dialog. This allows you to control whether websites may create caches and databases and how large those caches and databases may be.Screen shot of the updated Delete Browsing History dialog showing the new wording of the Cookies option to include web site data, specifically databases created by Web sites.
    Screen shots of the new Caches and databases tab of the Website Data Settings dialog and the updated Delete Browsing History dialog

    Looking Ahead

    The W3C WebApp Working Group continues to drive IndexedDB to completion by making important improvements and reducing the number and scope of changes made to the spec.  This is an important step for Web developers building on this technology in the near future, including in Windows 8 and IE10.

    We look forward to seeing how you use IndexedDB in your sites and apps, and welcome your feedback on IndexedDB in IE10.

    —Israel Hilerio, Ph.D., Principal Program Manager, Internet Explorer

     

    WebSockets in Windows Consumer Preview

    4:59 pm - March 19, 2012 in IEBlog

    In Windows 8 Consumer Preview and Server Beta, IE10 and all other Microsoft WebSocket client and server features now support the final version of the IETF WebSocket Protocol. In addition, IE10 implements the W3C WebSocket API Candidate Recommendation.

    WebSockets are stable and ready for developers to start creating innovative applications and services. This post provides a simple introduction to the W3C WebSocket API and its underlying WebSocket protocol. The updated Flipbook demo uses the latest version of the API and protocol.

    In my previous post, I introduced WebSocket scenarios:

    WebSockets enable Web applications to deliver real-time notifications and updates in the browser. Developers have faced problems in working around the limitations in the browser’s original HTTP request-response model, which was not designed for real-time scenarios. WebSockets enable browsers to open a bidirectional, full-duplex communication channel with services. Each side can then use this channel to immediately send data to the other. Now, sites from social networking and games to financial sites can deliver better real-time scenarios, ideally using same markup across different browsers.

    Since that September 2011 post, the working groups have made significant progress. The WebSocket protocol is now an IETF proposed standard protocol. In addition, the W3C WebSocket API is a W3C Candidate Recommendation.

    Introduction to the WebSocket API Using an Echo Example

    The code snippets below use a simple echo server created with ASP.NET’s System.Web.WebSockets namespace to echo back text and binary messages that are sent from the application. The application allows the user to type in text to be sent and echoed back as a text message or draw a picture that can be sent and echoed back as a binary message.

    Screen shot of WebSockets echo sample application.

    For a more complex example that allows you to experiment with latency and performance differences between WebSockets and HTTP polling, see the Flipbook demo.

    Details of Connecting to a WebSocket Server

    This simple explanation is based on a direct connection between the application and the server. If a proxy is configured, then IE10 starts the process by sending a HTTP CONNECT request to the proxy.

    When a WebSocket object is created, a handshake is exchanged between the client and the server to establish the WebSocket connection.

    Diagram illustrating an HTTP GET Upgrade Request from an HTTP Client to an HTTP Server.

    IE10 starts the process by sending a HTTP request to the server:

    GET /echo HTTP/1.1

    Host: example.microsoft.com

    Upgrade: websocket

    Connection: Upgrade

    Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

    Origin: http://microsoft.com

    Sec-WebSocket-Version: 13

    Let’s look at each part of this request.

    The connection process starts with a standard HTTP GET request which allows the request to traverse firewalls, proxies, and other intermediaries:

    GET /echo HTTP/1.1

    Host: example.microsoft.com

    The HTTP Upgrade header requests that the server switch the application-layer protocol from HTTP to the WebSocket protocol.

    Upgrade: websocket

    Connection: Upgrade

    The server transforms the value in the Sec-WebSocket-Key header in its response to demonstrate that it understands the WebSocket protocol:

    Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

    The Origin header is set by IE10 to allow the server to enforce origin-based security.

    Origin: http://microsoft.com

    The Sec-WebSocket-Version header identifies the requested protocol version. Version 13 is the final version in the IETF proposed standard:

    Sec-WebSocket-Version: 13

    If the server accepts the request to upgrade the application-layer protocol, it returns a HTTP 101 Switching Protocols response:

    Diagram illustrating an HTTP 101 Switching Protocols Respsonse from an HTTP Server Client to an HTTP Client.

    HTTP/1.1 101 Switching Protocols

    Upgrade: websocket

    Connection: Upgrade

    To demonstrate that it understands the WebSocket Protocol, the server performs a standardized transformation on the Sec-WebSocket-Key from the client request and returns the results in the Sec-WebSocket-Accept header:

    Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

    IE10 then compares Sec-WebSocket-Key with Sec-WebSocket-Accept to validate that the server is a WebSocket server and not a HTTP server with delusions of grandeur.

    The client handshake established a HTTP-on-TCP connection between IE10 and server. After the server returns its 101 response, the application-layer protocol switches from HTTP to WebSockets which uses the previously established TCP connection.

    HTTP is completely out of the picture at this point. Using the lightweight WebSocket wire protocol, messages can now be sent or received by either endpoint at any time.

    Diagram illustrating WebSocket messages being sent between two Web sockets.

    Programming Connecting to a WebSocket Server

    The WebSocket protocol defines two new URI schemes which are similar to the HTTP schemes.

    • "ws:" "//" host [ ":" port ] path [ "?" query ] is modeled on the “http:” scheme. Its default port is 80. It is used for unsecure (unencrypted) connections.
    • "wss:" "//" host [ ":" port ] path [ "?" query ] is modeled on the “https:” scheme. Its default port is 443. It is used for secure connections tunneled over Transport Layer Security.

    When proxies or network intermediaries are present, there is a higher probability that secure connections will be successful, as intermediaries are less inclined to attempt to transform secure traffic.

    The following code snippet establishes a WebSocket connection:

    var host = "ws://example.microsoft.com";

    var socket = new WebSocket(host);

    ReadyState – Ready … Set … Go …

    The WebSocket.readyState attribute represents the state of the connection: CONNECTING, OPEN, CLOSING, or CLOSED. When the WebSocket is first created, the readyState is set to CONNECTING. When the connection is established, the readyState is set to OPEN. If the connection fails to be established, then the readyState is set to CLOSED.

    Registering for Open Events

    To receive notifications when the connection has been created, the application must register for open events.

    socket.onopen = function (openEvent) {

    document.getElementById("serverStatus").innerHTML = 'Web Socket State::' + 'OPEN';

    };

    Details Behind Sending and Receiving Messages

    After a successful handshake, the application and the Websocket server may exchange WebSocket messages. A message is composed as a sequence of one or more message fragments or data “frames.”

    Each frame includes information such as:

    • Frame length
    • Type of message (binary or text) in the first frame in the message
    • A flag (FIN) indicating whether this is the last frame in the message

    Diagram illustrating the contents of WebSocket frames.

    IE10 reassembles the frames into a complete message before passing it to the script.

    Programming Sending and Receiving Messages

    The send API allows applications to send messages to a Websocket server as UTF-8 text, ArrayBuffers, or Blobs.

    For example, this snippet retrieves the text entered by the user and sends it to the server as a UTF-8 text message to be echoed back. It verifies that the Websocket is in an OPEN readyState:

    function sendTextMessage() {

    if (socket.readyState != WebSocket.OPEN)

    return;

     

    var e = document.getElementById("textmessage");

    socket.send(e.value);

    }

    This snippet retrieves the image drawn by the user in a canvas and sends it to the server as a binary message:

    function sendBinaryMessage() {

    if (socket.readyState != WebSocket.OPEN)

    return;

     

    var sourceCanvas = document.getElementById('source');

    // msToBlob returns a blob object from a canvas image or drawing

    socket.send(sourceCanvas.msToBlob());

    // ...

    }

    Registering for Message Events

    To receive messages, the application must register for message events. The event handler receives a MessageEvent which contains the data in MessageEvent.data. Data can be received as text or binary messages.

    When a binary message is received, the WebSocket.binaryType attribute controls whether the message data is returned as a Blob or an ArrayBuffer datatype. The attribute can be set to either “blob” or “arraybuffer.”

    The examples below use the default value which is “blob.”

    This snippet receives the echoed image or text from the websocket server. If the data is a Blob, then an image was returned and is drawn in the destination canvas; otherwise, a UTF-8 text message was returned and is displayed in a text field.

    socket.onmessage = function (messageEvent) {

    if (messageEvent.data instanceof Blob) {

    var destinationCanvas = document.getElementById('destination');

    var destinationContext = destinationCanvas.getContext('2d');

    var image = new Image();

    image.onload = function () {

    destinationContext.clearRect(0, 0, destinationCanvas.width, destinationCanvas.height);

    destinationContext.drawImage(image, 0, 0);

    }

    image.src = URL.createObjectURL(messageEvent.data);

    } else {

    document.getElementById("textresponse").value = messageEvent.data;

    }

    };

    Details of Closing a WebSocket Connection

    Similar to the opening handshake, there is a closing handshake. Either endpoint (the application or the server) can initiate this handshake.

    A special kind of frame – a close frame – is sent to the other endpoint. The close frame may contain an optional status code and reason for the close. The protocol defines a set of appropriate values for the status code. The sender of the close frame must not send further application data after the close frame.

    When the other endpoint receives the close frame, it responds with its own close frame in response. It may send pending messages prior to responding with the close frame.

    Diagram illustrating the Close frame message and response.

    Programming Closing a WebSocket and Registering for Close Events

    The application initiates the close handshake on an open connection with the close API:

    socket.close(1000, "normal close");

    To receive notifications when the connection has been closed, the application must register for close events.

    socket.onclose = function (closeEvent) {

    document.getElementById("serverStatus").innerHTML = 'Web Socket State::' + 'CLOSED';

    };

    The close API accepts two optional parameters: a status code as defined by the protocol and a description. The status code must be either 1000 or in the range 3000 to 4999. When close is executed, the readyState attribute is set to CLOSING. After IE10 receives the close response from the server, the readyState attribute is set to CLOSED and a close event is fired.

    Using Fiddler to See WebSockets Traffic

    Fiddler is a popular HTTP debugging proxy. There is some support in the latest versions for the WebSocket protocol. You can inspect the headers exchanged in the WebSocket handshake:

    Screen shot of Fiddler showing a WebSocket request.

    All the WebSocket messages are also logged. In the screenshot below, you can see that “spiral” was sent to the server as a UTF-8 text message and echoed back:

    Screen shot of Fiddler showing a WebSocket response.

    Conclusion

    If you want to learn more about WebSockets, you may watch these sessions from the Microsoft //Build/ conference from September 2011:

    If you’re curious about using Microsoft technologies to create a WebSocket service, these posts are good introductions:

    I encourage you to start developing with WebSockets today and share your feedback with us.

    —Brian Raymor, Senior Program Manager, Windows Networking

     
     
     
     
     
     
    It's All About Search | © clsc.net |
    2012.05.2122:34
    Tech used here: Valid HTML - Valid CSS - Valid RSS - JavaScript - PHP - Smarty - MySQL - and a partridge in a pear tree.