IEBlog

May 2013 Internet Explorer Updates

ieblog — Tue, 14 May 2013 19:38:57 GMT

Microsoft Security Bulletin MS13-037 - Critical

This security update resolves eleven privately reported vulnerabilities in Internet Explorer. The most severe vulnerabilities could allow remote code execution if a user views a specially crafted Web page using Internet Explorer. An attacker who successfully exploited the most severe of these vulnerabilities could gain the same user rights as the current user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

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

Recommendation. Most customers have automatic updating enabled and will not need to take any action because this security update will be downloaded and installed automatically. Customers who have not enabled automatic updating need to check for updates and install this update manually. For information about specific configuration options in automatic updating, see Microsoft Knowledge Base Article 294871.

For administrators and enterprise installations, or end users who want to install this security update manually, Microsoft recommends that customers apply the update immediately using update management software, or by checking for updates using the Microsoft Update service.

Microsoft Security Bulletin MS13-038 – Critical

This security update resolves one publicly disclosed vulnerability in Internet Explorer. The vulnerability could allow remote code execution if a user views a specially crafted Web page using Internet Explorer. An attacker who successfully exploited this vulnerability could gain the same user rights as the current user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

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

This security update also addresses the vulnerability first described in Microsoft Security Advisory 2847140.

Recommendation. Most customers have automatic updating enabled and will not need to take any action because this security update will be downloaded and installed automatically. Customers who have not enabled automatic updating need to check for updates and install this update manually. For information about specific configuration options in automatic updating, see Microsoft Knowledge Base Article 294871.

Microsoft Security Advisory (2755801)

Today, we also announced the availability of an update for Adobe Flash Player in Internet Explorer 10 on all supported editions of Windows 8 and Windows Server 2012. The details of the vulnerabilities are documented in Adobe security bulletin APSB13-14

The update addresses vulnerabilities in Adobe Flash Player by updating the affected Adobe Flash libraries contained within Internet Explorer 10. For more information, see the advisory.

Most customers have automatic updating enabled and will not need to take any action because this update will be downloaded and installed automatically. Customers who have not enabled automatic updating need to check for updates and install this update manually. For information about specific configuration options in automatic updating, see Microsoft Knowledge Base Article 294871.

— Ceri Gallacher, Program Manager, Internet Explorer

W3C Transitions Pointer Events to Candidate Recommendation

ieblog — Thu, 09 May 2013 22:35:02 GMT

Today, the W3C published Pointer Events as a Candidate Recommendation, an important step towards a standard and interoperable way to handle input from touch, pen, mouse, and more. This fast 5-month progression from First Public Working Draft to Candidate Recommendation is a mark of the effective collaboration between Microsoft, Google, Mozilla, Opera, Nokia, jQuery, and others to help sites take advantage of new interactive hardware on the Web.

Candidate Recommendation indicates the W3C considers the specification widely reviewed and satisfying the Working Group’s technical requirements. It signals a call for additional implementations to inform the group. The Pointer Events Working Group is also now actively producing tests to validate implementations of the specification. The recent Test the Web Forward event, sponsored by Microsoft, helped fuel this effort with nearly two dozen new test cases.

Increasingly, consumers browse the web with a broad range of devices; with touch, mouse and keyboard. By using pointer events, developers can write to a unified model that allows sites to be responsive to many types of input. Web developers can take advantage of pointer events in IE10 today, and in other browsers using polyfills like Hand.JS. We’ve also created a new portal on WebPlatform.org to help you learn more and try pointer events out. Pointer Events is one of many ways we’ve made touch fast and fluid on the Web.

Jacob Rossi

Program Manager

Test the Web Forward – Seattle 2013

ieblog — Fri, 26 Apr 2013 16:39:16 GMT

On April 12-13, Microsoft hosted a record-setting Test the Web Forward event to advance the Web by creating interoperability tests. Dozens of volunteers from Adobe, AT&T, Blackberry, Mozilla, and many other local companies joined us at our Seattle offices to learn about Web standards testing, how to write CSS and HTML tests, as well as the tools available for test suite management. Attendees from around the country - and even Canada – contributed to create a record-breaking 514 overall new tests.

Why Tests?

The quality and correctness of different browsers’ HTML and CSS standards compliance continues to vary widely. The W3C requires independent tests of all normative requirements in a specification in order to move a W3C Web specification from a candidate recommendation to an official recommendation. These tests are used to ensure that at least two browsers fully support each normative statement. As you might imagine, creating all of these tests is daunting; HTML5 is expected to need well over 100,000 tests, to say nothing of CSS3 modules, WebApps, Media Extensions, etc. We have submitted thousands of test cases for HTML, CSS, and SVG that can be viewed at the W3C and the Internet Explorer Test Center, however more tests are still needed. These tests benefit all browsers – and ultimately the entire Web developer community – by ensuring a consistent, predictable behavior. As different browsers improve their same-markup support, we can all realize the promise of HTML5 and CSS3.

A few years ago, several members of the standards community turned to crowd-sourcing to help create new tests, this resulted in Test the Web Forward events.

With the sponsorship of major players like Microsoft, Adobe, Google, and Mozilla, the Web community has come together, running local test-writing sprints around the world—France, China, Australia, and the US. Each sprint not only generates hundreds of tests, but also engages with and educates Web developers about the specifications that make up the Web platform.

Inside the Seattle Event

Our friends at Adobe were instrumental in setting up a successful event, building upon their experience in running previous events. In Seattle we kicked off the hack-a-thon on Friday night, with inspirational and informative presentations from Mozilla's fantasai (Elika Etemad), Adobe's Rebecca Hauck, and Microsoft's Kris Krueger, explaining why we need tests, what type of tests are available, and how to create them. Here’s a quick outline:

Stand-alone tests typically rely on visual verification: if a failure condition occurs, red content will show.

Reference tests compare a test against a visual reference that has no dependency on the feature being tested. Note that the test includes a link to the reference test against which is should be compared. For example, if you wanted to test that DIVs render background colors correctly, you might make a ref test using TABLEs.

Object Model tests depend on a JavaScript test harness; they verify that the object model reflects what static style sheets specify. For instance, this CSS media query test.

These presentations were followed by 2-minute pitches from Saturday's session test leaders on why participants might want to pick a particular focus (CSS Flexbox, Pointer Events, CSS Transforms, CSS OM, Backgrounds & Borders, Exclusions, or HTML5), though session participants were free to write tests against any API or spec they felt passionate about.

Following breakfast the next morning, participants broke up into three rooms with session leaders helping out in each. Each area was staffed by experts (in addition to the speakers from the previous evening): Arron Eicholz (Microsoft, CSS); Jacob Rossi (Microsoft, Pointer Events); Sylvain Galineau (Adobe [formerly Microsoft], CSS); Alan Stearns (Adobe, CSS); Dave Methvin (President of jQuery, HTML).

The leaders instructed everyone on how to determine where tests were needed and how to create code that tested the specific assertion that we wanted to capture. Volunteers could either work on their own, work in small groups, or get 1:1 help with the experts.

When all was said and done, the sprint generated 514 submitted tests, just edging out the record set by the Paris test sprint and setting a new bar for upcoming sprints to beat. After a few celebratory drinks, the end of the night saw the raffling off of a Surface Pro which was won by a student volunteer who joined us from the University of Washington.

You Can Help Too!

In IE10, we have added support for a long list of new standard features across CSS, HTML, SVG and the DOM. We have published some of our test cases for these new features on our IE Test Center. We will be submitting more, but we still need help from the community to get the right tests written and move these specs forward.

We are excited to be part of the community working towards a more innovative and interoperable Web. We support several initiatives in this direction, like the recent donation of JavaScript documentation to Webplatform.org, or our continued efforts to simplify cross-browser testing with modern.ie. If you want to help move the Web forward, too, come and join us at one of the next Test the Web Forward events! In the meanwhile, you can learn how to contribute tests, or review existing tests online. To hear about upcoming events and to stay in touch with the rest of the Test the Web Forward community, please subscribe to our W3C mailing list: public-testtwf. If test writing sounds too intense, but you are still knowledgeable and passionate about the Web, you can get involved with the WebPlatform Docs project and help document the Web.

For more info and updates, follow our Internet Explorer developer relations handle on Twitter @IEDevChat, this initiative’s handle @testthewebfwd and in particular #testtwf.

We will keep you posted on upcoming events and we are looking forward to meeting you soon!

—John Jansen, Kris Krueger, Arron Eicholz, and Jacob Rossi – Internet Explorer

Enabling Professional-Quality Online Video: New Specifications for Interoperable Captioning

ieblog — Thu, 25 Apr 2013 15:58:34 GMT

Video captioning on the Web is about to get significantly better, putting in place another critical building block for enabling professional-quality online video delivery and playback. To achieve the experience of broadcast television, the Web needs to provide captioning capabilities including word highlighting, tight synchronization between captions and spoken word, flexible caption positioning, caption styling, and caption animations – all of which are part of a recently published profile specification from the W3C Timed Text Working Group (TTWG). Microsoft has joined with content owners, video distributors, and device providers in developing the specifications to ensure interoperability and streamline closed caption authoring and delivery. For content and tool providers, the specification enables authoring of interoperable caption files for delivery to a wide variety of software and devices, while meeting evolving industry requirements.

Captioning is an intrinsic part of any professional-quality video experience—and the impact goes far beyond enabling the hearing impaired to gain full access to the video content. Captions are turned on in loud environments, such as at the gym. Captioning is used to help us all understand foreign language films. Of course, I’m surely not the only person who turns on captions to better understand difficult accents in movies streamed on Netflix.

In February 2013, Microsoft joined industry stakeholders in the W3C Timed Text Working Group (TTWG) to deliver the TTML Simple Delivery Profile for Closed Captions (SDP-US) profile specification. This new profile was created with input from media industry experts from DECE, SMPTE, EBU and industry players including Adobe, MovieLabs, NBC Universal, Cox, Apple, Netflix and Microsoft.

SDP-US is based on Timed Text Markup Language (TTML) (a caption interchange specification that has been used in the professional video industry for years) and clearly defines key caption format features like layout, style, timing and content requirements, enabling content authors and tool providers to easily create interoperable caption files that meet evolving industry requirements. SDP-US will help streamline creation of closed captions to deliver media content to the Web across a wide variety of software and devices – in a browser like Internet Explorer, on devices such as Xbox or through applications built using the Microsoft Media Player Framework.

Internet Explorer was one of the first browsers to include early support for HTML5-based video captioning via the <track> element with TTML and WebVTT file formats. Since then, we’ve heard clear feedback from content authors: They need an interoperable, simple and full-featured captioning solution that meets emerging requirements for browsers and other software on Internet-connected devices. SDP-US will meet this need by defining a streamlined set of captioning capabilities for the HTML5 <track> element. Developers will be able to add captioning to an HTML5 video by providing a caption file that contains a styled text representation of the video dialog or actions and by using the <track> element to render and display the contents of that file.

To illustrate some of the power of the new SDP-US captioning specification, here’s an example of how Internet Explorer renders captions with a default plain text style and position:

With SDP-US, caption authors have much more flexibility in caption positioning and styling, as shown in the below examples:

Professional-quality online video is a forthcoming reality, enabled by emerging Web specifications and powerful content delivery infrastructure. Captioning is an important building block for enabling professional-quality video, and Microsoft is actively working with industry partners to enable rich captioning experiences. If you are working on Internet video, we invite you to review the new SDP-US profile, join the industry discussion, start considering how your caption content can adapt to SDP-US, and let us have your feedback.

-- Sandeep Singhal, Group Program Manager, Internet Explorer

April 2013 Internet Explorer Updates

ieblog — Tue, 09 Apr 2013 18:17:44 GMT

Microsoft Security Bulletin MS13-028 - Critical

This security update resolves two privately reported vulnerabilities in Internet Explorer. The most severe vulnerabilities could allow remote code execution if a user views a specially crafted Web page using Internet Explorer. An attacker who successfully exploited these vulnerabilities could gain the same user rights as the current user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

Microsoft Security Advisory (2755801)

Today we also released an update that addresses vulnerabilities in Adobe Flash Player in Internet Explorer 10 on Windows 8. The details of the vulnerabilities are documented in Adobe security bulletin APSB13-11. The majority of customers have automatic updates enabled and will not need to take any action because the update will be downloaded and installed automatically. For those manually updating, we encourage you to read the advisory and apply this update as quickly as possible.

This update addresses the vulnerabilities in Adobe Flash Player by updating the affected Adobe Flash binaries contained within Internet Explorer 10. For more information, see the advisory.

— Ceri Gallacher, Program Manager, Internet Explorer

New on modern.IE: Free VM Downloads, Windows 8 QuickStart Kits, Enhanced Code-Scanning Tools, and More

ieblog — Tue, 02 Apr 2013 14:12:00 GMT

Today, we are updating modern.IE with enhanced tools and resources to help you test your sites for modern browsers like Internet Explorer 9 and 10, while also helping you support older versions of browsers. These enhancements address the most common feedback, suggestions, and requests that we have received from enthusiastic users since introducing the site in January.

With today’s update, we are making available a new offer, new downloads, and tool enhancements on modern.IE. Some highlights include:

Order a Windows QuickStart Kit for Mac Developers, including Parallels Desktop 8 and Windows 8 on a USB stick shipped to you for a $25 donation to select charities (Update 10:45am PDT 4/2/2013: The Windows Quickstart offer sold out quickly. Given how popular these were, we will look into making other offers available in the near future.)
Download new virtual machines for IE10 on Windows 7 and IE8 on Windows XP
Scan a Web page URL now identifies more interoperability issues, even for sites located behind a firewall.
Availability in 18 languages

We continue to offer 3 months of free BrowserStack access so you can easily test across browsers and OS platforms without changing your primary development environment.

We are excited to see the developer reception to modern.IE so far. We appreciate the thoughtful feedback in tweets and suggestions you have offered on ways we can help save time and improve how you test your Web experiences. Today’s modern.IE release incorporates much of that feedback. Please do keep the comments coming, as we will continue to update the site regularly.

For the Mac user: Get the Windows QuickStart Kit including Windows 8 with Parallels Desktop 8

We heard that the most common way you test across browsers is through virtualization of browser and operating system combinations using your favorite virtualization platform, such as Hyper-V, VMWare, VirtualBox, or Parallels. However, costs to purchase software and licensing can be difficult if you’re that startup looking for your first big breakthrough.

Today we’re making it just a little easier with a new combo offer: We’ll ship you a copy of Windows 8 and Parallels Desktop 8 for Mac virtualization on a USB stick for a $25 donation to your favorite charity, courtesy of our friends at Swish. (Update 10:45am PDT 4/2/2013: The Windows Quickstart offer sold out quickly. Given how popular these were, we will look into making other offers available in the near future.)

We only have a limited supply available. You can get the details and pre-order here.

Download new virtual machines

You told us that you want to be able to access as many testing environments as possible with minimal extra effort. Today we announce new virtual machines that are available for free:

IE10 on Windows 7
IE8 on Windows XP

We also received lots of feedback from developers on Mac and Linux concerning how to simplify your testing experience. We have added Parallels for Mac images for all IE versions. Many of you had some challenges downloading the VMs previously, and in response, we have updated the VM installation process to be simpler. Complete download information is available here.

Scan a Web page URL for common coding issues: Enhanced tools now also run behind a firewall

Based on your feedback and experience, we have enhanced the scan a Web page URL tool to provide more flexibility and to offer more detailed and actionable guidance. Over the past two months, you have scanned hundreds of thousands of URLs – from top sites like Facebook, Pandora, and Yahoo! to the local pizza store near you. We have studied the most common coding issues reported on these sites and looked at which issues resulted in fixes or enhancements to the site. We also received hundreds of new ideas directly from the community. The result was a set of new enhancements that make the scanner a more complete testing solution for your site:

Scan your Web pages behind a firewall: The most common feedback we heard is that today, so many sites include authentication, are internal or commercial line-of-business Web apps, or are otherwise not available to the public Internet. Now, you can install a local instance of modern.IE to scan your code while keeping your project secure from others (including Microsoft). Install it through node.js and access your site via localhost.
Deeper scan for common IE compatibility issues: We heard from you that the first step when testing for IE is knowing whether your site is on the Compatibility View list, but what you really want to know is how to fix the underlying compatibility issues. Now on modern.IE, you can scan your site using our Compat Inspector tool using browser automation, provided by Sauce Labs, without adding a single line of code to your site. The result is a line-item list of suggested fixes.
Breakpoint detection for responsively designed sites – We found that you were most interested in learning how to adapt your Web experiences to support the growing range of devices – from phones and tablets to the big screen IE on XBOX. About 20% of top traffic and influential sites now offer some form of mobile-optimized experience – a significant growth in the past year. The scan a Web page URL tool now has built-in logic to detect when a Web page has been optimized for the common horizontal screen resolutions (or “breakpoints”). While we recommend that you let your site’s content determine which breakpoints to build for, we do suggests the most common ones across a range of devices.
Touch-optimization detection: As touch support evolves toward a Web standard, we also learned that sites currently implement touch support in a variety of ways. modern.IE now detects Touch functionality across multiple JavaScript-, HTML-, and CSS- based techniques.
Browser plug-ins: Recently we announced that Internet Explorer 10 in Windows 8 and Windows RT have been updated to enable Flash content to run by default. If you want to check to see if your site is on the Flash CV block list, you can now scan for this on modern.IE.

We have also made dozens of bug fixes in the scanning tool to handle Web pages that used less common practices or frameworks & libraries. If you scanned a Web page and got an error, we encourage you to try it again!

modern.IE for the World-Wide Web

modern.IE will be available in 18 languages throughout the next two days, making it a bit easier for site developers around the world. The supported languages include Arabic, Bahasa Indonesia, Chinese (Simplified, Traditional, and Hong Kong), Dutch, French, German, Italian, Japanese, Korean, Portuguese (Brazilian), Russian, Spanish (Spain and Latin America), Swedish, Thai, Turkish, and Vietnamese.

modern.IE – Testing made easier

We will continue to enhance modern.IE with your help. Please continue to share your feedback on this resource. Please continue to let us know what you like, and what we’re missing!

-- Sandeep Singhal, Group Program Manager, Internet Explorer

Spring Forward: Advancing Historical Date and Time Calculations on the Web

ieblog — Mon, 25 Mar 2013 18:10:00 GMT

Spring Forward: Advancing Historical Date and Time Calculations on the Web

Web developers want to create world-ready applications to reach a global audience. Internet Explorer 10 brings the historical Daylight Saving Time, already available on the underlying OS, to the Web developer. This enables apps and sites to interact with historic dates and times across various time zones more accurately.

Earlier this year we explored the emerging ECMAScript Internationalization APIs that will enable things like currency representation and locale sensitive string comparison from within the Web standards platform, scenarios that previously required native interoperability or use of a plug-in. Along the same theme of making the Web platform world-ready, we published a demo exploring how browsers interact with historical date and time zone information.

Challenges with historical date and time calculations

When interacting with historical dates, like interpreting historical stock prices or birthdays or historical events, Web developers often have to perform validation on the server. Developers have to rely on server because Daylight Saving Time adjustments done to the dates by JavaScript engines today are not as accurate as platforms commonly run on the server like .NET, PHP / Perl, and Java. In addition to historical JavaScript dates being inaccurate, they are often not interoperable among browser platforms. Hence, developers are not able to take reliable dependency on the DST adjusted dates generated in JavaScript.

IE10 is the first browser with more accurate DST adjusted dates aligned with the changes made to section 15.9.1.8 of the ECMAScript 6 draft specification. We expanded the capabilities of the Web platform based on the scenarios where Web developers have to interact with the server for accomplishing their needs. We looked at how JavaScript engines interpret historical dates and adjust for DST. We noticed a shortcoming in the ECMAScript standards specification that prevents existing JavaScript implementations from being more accurate in adjusting for daylight savings time. We worked with the ECMAScript standards committee and proposed a specification change to drive more clarity into the next version of the ECMAScript specification.

Exploring the Test Drive Demo

To illustrate this problem and see how your favorite browser deals with historical dates, you can play with the Historic Dates Test Drive demo by clicking on any icon of an event in aerospace history at the bottom of the demo. When you do so, the browser reads the historic date when the event occurred, and shows the date and time by applying the daylight saving rule that the browser defaulted to for when the event occurred. The demo then verifies if the historic date and daylight saving is correct or not.

In the above case, when viewing the historic date for when the IMAGE spacecraft was launched, IE10 running on a Windows 8 machine in Pacific Standard Time zone is now accurately able to determine the correct date and daylight saving time for the historic event.

Note: Daylight savings time is not applicable to all time zones, and there do exist time zones where the daylight savings rules have not changed ever. In case your system is currently in such a time zone, we’d recommend you to change your system’s time zone to one where the daylight savings rules exist and have changed over a period of time (like Pacific Standard Time) and re-run the demo. While IE10 does immediately picks up the system time zone change, in case you are using any other browser, you might need to restart the browser for the updated time zone to take effect.

Improved handling of historic dates and times in IE10

Let us take a closer look at to see how the current ECMAScript specification impacts the accuracy of adjusting dates for DST in JavaScript:

Section 15.9.1.8 of ECMAScript 5.1, specifies that JavaScript implementations like Internet Explorer’s Chakra engine should typically follow while dealing with historic dates:

The implementation of ECMAScript should not try to determine whether the exact time was subject to daylight saving time, but just whether daylight saving time would have been in effect if the current daylight saving time algorithm had been used at the time. This avoids complications such as taking into account the years that the locale observed daylight saving time year round.

If the host environment provides functionality for determining daylight saving time, the implementation of ECMAScript is free to map the year in question to an equivalent year (same leap-year-ness and same starting week day for the year) for which the host environment provides daylight saving time information. The only restriction is that all equivalent years should produce the same result.

In simplified words, this means that to deal with a historical date, a JavaScript implementation should either apply the current daylight saving time algorithm to a historic date, or determine the day for Jan 1st of a year, calculate if it was a leap year, find the current daylight saving time rules for a year with the same attributes (start day and leap year), and apply that particular daylight savings time to the historical date. As an example for the latter, the year 1972 was a leap year that started on a Saturday. And, the next leap year that started on a Saturday was 2000. According to the language specification, JavaScript implementations could either use the current, or use the daylight saving rules for year 2000 while manipulating any dates for the year 1972.

There are two key problems when either of the above rules is used to apply daylight saving time rules to historic dates. First, the daylight saving rules for a particular time zone are not constant and change over time. This could lead to wrong rules being applied to a historic date. Second, for the time zones where daylight saving rules have changed over a period of time, Web applications are no longer able to maintain parity for those historical dates as calculated by the OS platform that they are running on, often forcing developers to hack around such interoperability problems between Web applications and the platform that they run on.

The ECMAScript 5.1 specification text in 15.9.1.8 as we saw above allows implementations to be as wrong as they would like about daylight savings adjustments, but constrains how correct they should try to be. This is somewhat counterintuitive, and in practice, has not succeeded in producing consensus between browsers. Instead of constraining time zone offset behavior as in section 15.9.1.8, the specification should leave DaylightSavingsTA implementation dependent.

Our testing showed that, none of the existing browser implementations (latest versions) fully adheres to either the behavior specified in the standard across platforms or accurate in DST adjustments when dealing with dates. Here are some examples that show the difference in the US Pacific time zone:

Date	Windows					Debian	Mac
	IE9	Chrome	Firefox	Opera	Safari	Node	Node	Chrome	Firefox	Safari
4/1/2000	420	420	420	420	420	420	480	480	480	420

Note that on this date Chrome, FireFox and Node are inconsistent between OSes. Almost everyone is actually wrong though, the actual DST adjustment was 480.

Date	Windows					Debian	Mac
	IE9	Chrome	Firefox	Opera	Safari	Node	Node	Chrome	Firefox	Safari
3/10/2011	480	480	480	480	480	480	480	480	480	480
3/10/2109	480	480	480	480	420	480	480	480	420	420

Note that on this date, a few environments are again violating ES5.1 rules (these two years both start on Tuesday and are not leap years), but here there are disagreements even on a single OS (both on Windows and Mac).

Looking Ahead

Starting with Internet Explorer 10, the Chakra engine now uses the daylight saving time information available from the Windows platform that the browser runs on for conversions between local time and UTC.

After we reported the spec issue and worked with the ECMAScript standards committee to drive more clarity into the next version of the ECMAScript specification to enable the Web platform to be interoperable and more accurate, the latest draft of the ECMAScript 6 specification now details how enhanced and accurate support for daylight saving time rules should be applied to dates to produce more accurate information. IE10 the first browser that conforms to the updated specification and we hope that other browsers will also enhance their support to address the issues in their next releases, allowing Web developers to create rich world ready applications.

As the Web platform continues to grow in importance, rich application logic is now often written entirely in JavaScript, including that used by calendaring applications, spreadsheets, project management software, etc. To allow developers to maintain compatibility, this change is only enabled in IE10’s standards mode. In case you calculate historic dates in your Web applications and have custom logic to work around the inaccuracies of the browsers, you might want to ensure that the custom logic still works properly as you upgrade your Web applications to work on IE10.

-- Suresh Jayabalan, Program Manager, JavaScript Team

IEAK 10 now available for Windows 7 and Windows 8

ieblog — Fri, 22 Mar 2013 18:11:30 GMT

Internet Explorer Administration Kit 10 (IEAK 10) now supports building custom Internet Explorer 10 packages for Windows 7 and Windows 8. IEAK 10 simplifies the creation, deployment, and management of customized Internet Explorer 10 packages. You can download IEAK 10 from http://ieak.microsoft.com.

Kevin Luu, Program Manager, Internet Explorer

Imagining a More Engaging Web: 3rd Anniversary of IE Test Drive

ieblog — Mon, 18 Mar 2013 16:02:44 GMT

As developers build on the full capabilities of HTML5, touch, and hardware accelerated graphics, the web today is more engaging for consumers than many imagined. The experiences developers are building today simply were not possible just a few years ago.

Saturday marked the third anniversary of the IE Test Drive site. What started as a few examples of hardware-accelerated HTML5 to help developers imagine the potential of the web, has grown to a collection of over 140 feature-packed demos. Test Drive gives you a taste of what’s possible with HTML5 and modern browsers on modern hardware: HTML5, CSS3, ECMAScript 5, touch, GPU-powered graphics, blazing performance, audio/video, mobile, games, and more.

The support you’ve shown is humbling – over the last three years the Test Drive has received over 130 million page views! That’s more than a page per second for the last three years! We’ve had a lot of fun building the demos, and thought we’d take a look back at some of our favorite demos along the way.

The IE Test Drive Site contains over 140 demos!

Demos

Audio Explosion	Touch, see, and hear IE10
CanvasPinball	The perfect work time break
Chalkboard	IE10 takes other browsers to school
FishBowl	HTML5, CSS3, Video, Audio, Canvas, Fish
FishIE	Started the fish revolution
Flying Images	Our very first Test Drive!
Galactic	Out of this world performance
Hamster Dance Revolution	Get ready to become addicted
Love is in the Air	We love you too
Minesweeper	Speed that’ll make your browser explode
Mr. Potato Gun	Actions speak louder than marketing videos
Psychedelic Browsing	Our “highest” viewed demo after 2am
Speed Reading	How fast can your browser speed read?
Touch Effects	Touch your way to a faster experience
Tracking Protection	Putting your privacy first

Looking Ahead

IE10 continues to deliver the best performance for real world Web sites on your Windows device, and the Test Drive is a great place to experience what’s possible yourself. Take the Test Drive for a spin today and let us know what you think!

We’re always excited and humbled by the amazing experiences developers are building on the web every day. Thank you for your continued feedback and for using IE10.

— Jon Aneja, Program Manager, Internet Explorer

Building Vyclone's Interactive Experience with HTML5

ieblog — Fri, 15 Mar 2013 17:07:06 GMT

Building Vyclone's Interactive Experience with HTML5

The Web is more engaging and productive for consumers, as developers unlock the full potential of HTML5. In this guest blog post, Anton Molleda of Plain Concepts talks about his experience and learnings while developing Vcylone, a social video editing experience built on HTML5 and many of the new features in next generation browsers like Internet Explorer 10. Vcyclone builds on capabilities like pointer events, multi-touch gestures, and hardware accelerated canvas and CSS3 to make this Web site feel more like an app.

— Rob Mauceri, Group Program Manager, Internet Explorer

Hello everyone,

My name is Anton Molleda and I work for Plain Concepts. These last few months the team at Internet Explorer has been collaborating with the awesome crew that makes up the hot up and coming social video startup Vyclone. As a Web developer, having the opportunity to push the envelope with what the Web can do is one of my passion points. Fortunately, I’ve been lucky enough to help out on this project. And today, I want to share with you some key learning we had while we worked together to create a video editor on the Web for Vyclone, using just HTML5 and JavaScript!

Vyclone is a social video platform that lets you co-create, sync and edit multiple views of a shared moment, effortlessly.

When Vyclone first started, it solely focused on mobile devices. But soon they realized that while the recording experience is great from a phone, editing that video was limited due to the screen size and power of the device. Thanks to the progress done these last few years in modern browsers, HTML5 was a viable option as the way to go to create this new tool.

The core of Vyclone’s Web editor is composed of three parts:

The video preview: Where a low quality version of the cut the user is creating can be watched (on the left)

The vidgrid: Where all the available sources are presented to the user showing a given point and time (on the right)

And the timeline: Which indicates a linear view of which source is playing over the course of the video. A source playing during a certain amount of time is called a cut (shown above the player controls)

As the user plays the video and starts adding new cuts to the timeline, the video preview switches to reflect the new source, and the vidgrid highlights the source file with triangle corners to identify to the user which video is selected.

So in building this out, we ran into a very interesting challenge with sheer amount of video manipulation, the performance we were getting back, and the user experience. Let’s dig into what we did to make this happen on the Web. So we’re using video, canvas and requestAnimationFrame (RAF). We have a video in the background that is played, and in each RAF we draw the active source into a canvas (in the video preview) or we calculate its new size and position into the vidgrid.

So far so good, but what happens when we let the user interact with it? For example, what happens when a user moves the timeline forward and back, or adds / removes video sources (cuts)? When we first started prototyping this out, we thought the standard approach would be to take care of that as soon as the event is fired - because that's the way we've been taught, right?

But what happens when those events can be fired tens of times per second, or even hundreds of times per second? And what if those handlers need to update the UI? Do we really need to force a layout refresh 130 times per second when the delta change could sometimes be less than a pixel? Talk about performance drag!

If your machine has an i7 with 8GB of RAM, you can probably afford computing power to do that. But what about people with an older rig? Or an ARM device? Those users will not have the same experience and will see the reaction time of the Web site slow way down.

Our first approach was to queue the action in the RAF but there were some problems with this approach, such as, you can RAF up the same function for the same "tick", effectively making things worse. To solve for this, our first approach was to have a variable that will tell us if the action was already queued up. Something like this:

var queued = false;
 
function myAction(){
   //your awesome code here
   queued = false;
}

function onEvent(evt){
   if(!queued){
      queued = true;
      requestAnimationFrame(myAction);
   }
}

This code is not bad but still has some problems. If you are doing something related with the event position (mouse or pointer) and a delta, you might find that you’ll struggle with this approach. The solution we used in the timeline is to accumulate the event value and process it on myAction:

var deltaX = 0,
    queued = false;
 
function myAction(){
   //your awesome code here uses deltaX
   deltaX = 0; // we reset the deltaX so it can be incremented 
               // next time onEvent is executed
   queued = false;
}
 
function onEvent(evt){
   if(!queued){
      queued = true;
      deltaX = evt.translationX; // in the case of a pointer, if you are 
                                 // using a mouse you will have to do some 
                                 // magic with pageX or similar :)
      requestAnimationFrame(myAction);
   }else{
      deltaX += evt.translationX;
   }
}

With this approach you should be pretty much ready to go. We kept adding functionality and then noticed some new problems popped up.

By handling those events when appropriate at each requestAnimationFrame we were able to achieve a higher level of responsiveness without sacrificing computing power. But since requestAnimationFrame executes the functions in the order, they are queued up so sometimes we were drawing before cleaning, or moving the timeline when we didn't have to and we had to create a lot of cumbersome code to make sure it got executed the order we wanted.

We saw that code wasn't very friendly and we were losing some cycles waiting for other actions to be performed so we decided to change again how we handled the input. It was at this moment that we thought about this as a game loop. If you’re not familiar in (simple) game architecture, the game loop is basically a continuous loop that gets executed regardless of the user interaction and splits apart when different events and actions should occur. From the Wikipedia article Game Programming, a simplified game loop in pseudo code could look like this:

while( user doesn't exit )
   check for user input
   run AI
   move enemies
   resolve collisions
   draw graphics
   play sounds
end while

That was exactly what we needed. Taking advantage of RAF we created a tick function that is executed continuously and inside this tick function we decide what we have to do depending on previous user input or other factors.

The simplified tick for the vidgrid is something like this:

   
function tick(){

   //we clean if we've changed the size of the quadrant
   if(needsClean){
      cleanCanvas();
   }

   // if we have to change the quadrant's frame because we are 
   // the active one (or the opposite)
   if(newFrame){
      drawFrame(); // we draw just the frame in a separate canvas so it
                   // doesn't need to be calculated all the time, and it 
                   // is still faster than copying from an image
   }

   //we draw the new frame if we are playing or seeking
   if(dirty){
      draw();
      drawFrameInQuadrant();
   }

   requestAnimationFrame(tick);
}

The values of needsClean, newFrame and dirty are updated on the event handlers (when the user is seeking, video playing, etc.).

It was this shift in the way we thought about the user interactions, going to a game loop mechanic, that allowed us to improve the performance and simplify our code in the editor.

Big takeaways, if you are building something is requires high interactivity and receives a lot of user input, think about how potentially using a game loop can make your life easier! It sure did for us. And if you haven’t had a chance to check out Vyclone’s sexy new Web editor (if I don’t say so myself), get going! Click ‘Remix’ on any video on Vyclone.com and you’ll see our Web editor. It works equally well with mouse or touch input. I highly recommend giving it a go on a Surface Pro!

Enjoy! Hit me up with some comments below if you have any questions!

— Anton Molleda, Plain Concepts