Tag Archives: Anniversary Update

Configure your app to start at log-in

For a long time, desktop PC users have been able to configure Win32 apps to start at startup or user log-in. This has also been possible for Desktop Bridge apps since the Windows 10 Anniversary Update (v10.0.14393.0). We’ve now extended this feature to allow regular Universal Windows Apps to take part in this also. This is available in Insider builds from Build 16226 onwards, along with the corresponding SDK. In this post, we’ll look at the code changes you need to make in your manifest and in your App class to handle the startup scenario, and how your app can work with the user to respect their choices.

Here’s a sample app, called TestStartup – the app offers a button to request enabling the startup behavior, and reports current status. Typically, you’d put this kind of option into a settings page of some kind in your app.

The first thing to note is that you must use the windows.startupTask Extension in your app manifest under the Extensions node, which is a child of the Application node. This is documented here. The same Extension declaration is used for both Desktop Bridge and regular UWP apps – but there are some differences.

  • Desktop Bridge is only available on Desktop, so it uses a Desktop-specific XML namespace. The new UWP implementation is designed for use generally on UWP, so it uses a general UAP namespace (contract version 5) – although to be clear, it is currently still only actually available on Desktop.
  • The Desktop Bridge EntryPoint must be “Windows.FullTrustApplication,” whereas for regular UWP it is the fully-qualified namespace name of your App class.
  • Desktop Bridge apps can set the Enabled attribute to true, which means that the app will start at startup without the user having to manually enable it. Conversely, for regular UWP apps this attribute is ignored, and the feature is implicitly set to “disabled.” Instead, the user must first launch the app, and the app must request to be enabled for startup activation.
  • For Desktop Bridge apps, multiple startupTask Extensions are permitted, each one can use a different Executable. Conversely, for regular UWP apps, you would have only one Executable and one startupTask Extension.
Desktop Bridge App UWP App


    DisplayName="Lorem Ipsum" />

    DisplayName="Lorem Ipsum" />

For both Desktop Bridge apps and regular UWP apps, the user is always in control, and can change the Enabled state of your startup app at any time via the Startup tab in Task Manager:

Also for both app types, the app must be launched at least once before the user can change the Disabled/Enabled state. This is potentially slightly confusing: if the user doesn’t launch the app and then tries to change the state to Enabled in Task Manager, this will seem to be set. However, if they then close Task Manager and re-open it, they will see that the state is still Disabled. What’s happening here is that Task Manager is correctly persisting the user’s choice of the Enabled state – but this won’t actually allow the app to be activated at startup unless and until the app is launched at least once first – hence the reason it is reported as Disabled.

In your UWP code, you can request to be enabled for startup. To do this, use the StartupTask.GetAsync method to initialize a StartupTask object (documented here) – passing in the TaskId you specified in the manifest – and then call the RequestEnableAsync method. In the test app, we’re doing this in the Click handler for the button. The return value from the request is the new (possibly unchanged) StartupTaskState.

async private void requestButton_Click(object sender, RoutedEventArgs e)
    StartupTask startupTask = await StartupTask.GetAsync("MyStartupId");
    switch (startupTask.State)
        case StartupTaskState.Disabled:
            // Task is disabled but can be enabled.
            StartupTaskState newState = await startupTask.RequestEnableAsync();
            Debug.WriteLine("Request to enable startup, result = {0}", newState);
        case StartupTaskState.DisabledByUser:
            // Task is disabled and user must enable it manually.
            MessageDialog dialog = new MessageDialog(
                "I know you don't want this app to run " +
                "as soon as you sign in, but if you change your mind, " +
                "you can enable this in the Startup tab in Task Manager.",
            await dialog.ShowAsync();
        case StartupTaskState.DisabledByPolicy:
                "Startup disabled by group policy, or not supported on this device");
        case StartupTaskState.Enabled:
            Debug.WriteLine("Startup is enabled.");

Because Desktop Bridge apps have a Win32 component, they run with a lot more power than regular UWP apps generally. They can set their StartupTask(s) to be Enabled in the manifest and do not need to call the API. For regular UWP apps, the behavior is more constrained, specifically:

  • The default is Disabled, so in the normal case, the user must run the app at least once explicitly – this gives the app the opportunity to request to be enabled.
  • When the app calls RequestEnableAsync, this will show a user-prompt dialog for UWP apps (or if called from a UWP component in a Desktop Bridge app from the Windows 10 Fall Creators Update onwards).
  • StartupTask includes a Disable method. If the state is Enabled, the app can use the API to set it to Disabled. If the app then subsequently requests to enable again, this will also trigger the user prompt.
  • If the user disables (either via the user prompt, or via the Task Manager Startup tab), then the prompt is not shown again, regardless of any requests from the app. The app can of course devise its own user prompts, asking the user to make manual changes in Task Manager – but if the user has explicitly disabled your startup, you should probably respect their decision and stop pestering them. In the sample code above, the app is responding to DisabledByUser by popping its own message dialog – you can obviously do this if you want, but it should be emphasized that there’s a risk you’ll just annoy the user.
  • If the feature is disabled by local admin or group policy, then the user prompt is not shown, and startup cannot be enabled. The existing StartupTaskState enum has been extended with a new value, DisabledByPolicy. When the app sees DisabledByPolicy, it should avoid re-requesting that their task be enabled, because the request will never be approved until the policy changes.
  • Platforms other than Desktop that don’t support startup tasks also report DisabledByPolicy.

Where a request triggers a user-consent prompt (UWP apps only), the message includes the DisplayName you specified in your manifest. This prompt is not shown if the state is DisabledByUser or DisabledByPolicy.

If your app is enabled for startup activation, you should handle this case in your App class by overriding the OnActivated method. Check the IActivatedEventArgs.Kind to see if it is ActivationKind.StartupTask, and if so, case the IActivatedEventArgs to a StartupTaskActivatedEventArgs. From this, you can retrieve the TaskId, should you need it. In this test app, we’re simply passing on the ActivationKind as a string to MainPage.

protected override void OnActivated(IActivatedEventArgs args)
    Frame rootFrame = Window.Current.Content as Frame;
    if (rootFrame == null)
        rootFrame = new Frame();
        Window.Current.Content = rootFrame;

    string payload = string.Empty;
    if (args.Kind == ActivationKind.StartupTask)
        var startupArgs = args as StartupTaskActivatedEventArgs;
        payload = ActivationKind.StartupTask.ToString();

    rootFrame.Navigate(typeof(MainPage), payload);

Then, the MainPage OnNavigatedTo override tests this incoming string and uses it to report status in the UI.

protected override void OnNavigatedTo(NavigationEventArgs e)
    string payload = e.Parameter as string;
    if (!string.IsNullOrEmpty(payload))
        activationText.Text = payload;

        if (payload == "StartupTask")
            requestButton.IsEnabled = false;
            requestResult.Text = "Enabled";
            SolidColorBrush brush = new SolidColorBrush(Colors.Gray);
            requestResult.Foreground = brush;
            requestPrompt.Foreground = brush;

Note that when your app starts at startup, it will start minimized in the taskbar. In this test app, when brought to normal window mode, the app reports the ActivationKind and StartupTaskState:

Using the windows.startupTask manifest Extension and the StartupTask.RequestEnableAsync API, your app can be configured to start at user log-in. This can be useful for apps which the user expects to use heavily, and the user has control over this – but it is still a feature that you should use carefully. You should not use the feature if you don’t reasonably expect the user to want it for your app – and you should avoid repeatedly prompting them once they’ve made their choice. The inclusion of a user-prompt puts the user firmly in control, which is an improvement over the older Win32 model.

Sample Code here.

Microsoft Edge and Continuum: Your desktop browser on Mobile

Continuum for Phones, available on select Windows 10 Mobile devices, allows customers to connect their phone to a monitor, projector, or TV for a full-sized desktop experience, powered by their phone. Because Microsoft Edge is built on the Universal Windows Platform, Microsoft Edge in Continuum is able to provide a full desktop browser experience.

Image of a Windows phone connected to a Lumia Display Dock.

Windows 10 phone connected to Lumia Display Dock for Continuum

Let’s walk through a quick overview of how Continuum works and a few key differences between Microsoft Edge running in Continuum and on a PC.

Using Continuum on Windows 10 Mobile

Continuum allows Windows 10 Mobile users to have a PC-like experience when connected to an external display and a mouse and keyboard. When connected (via a wired dock or via Bluetooth and Miracast), Universal Windows Apps like Office and Microsoft Edge will adapt their interface and behavior to provide a desktop-like experience tailored to mouse and keyboard input.

Check out the Continuum product page, FAQ, and Getting Started Guide to learn more about Continuum.

Microsoft Edge on Continuum

Microsoft Edge takes full advantage of the Universal Windows Platform to provide a complete desktop-like experience in Continuum — when the device is connected to a larger display, Microsoft Edge turns into a desktop browser, adapting the interface and rendering characteristics to match Microsoft Edge on PCs.

In fact, Microsoft Edge in Continuum is nearly indistinguishable from its PC twin, which is a fun party trick when presenting at events or in meetings!

Screen capture showing Microsoft Edge open to bing.com in Continuum mode on a display connected to a Windows 10 phone.

Microsoft Edge running in Continuum

To enable an experience that’s as true to the desktop equivalent as possible, there are a couple of important things to keep in mind.

One rendering engine

Because Microsoft Edge uses the same engine across all Windows 10 devices, the rendering behavior is the same across Windows 10 devices, including Windows 10 Mobile devices. The only differences are due to certain device-specific qualities – for example, codec support may be different on phones due to missing hardware acceleration, and Flash is not supported on Windows 10 Mobile. Because Windows 10 Mobile has a different background model, RTC is also currently not supported. Finally, Windows 10 Mobile does not support Flash in order to provide a modern, touch-focused, and power-efficient experience appropriate for a mobile device. Because of this, Flash is not supported in Microsoft Edge in Continuum.

Details for web developers

Developers in general won’t have to give any special consideration to Microsoft Edge in Continuum. By design, it will behave like a desktop client, including sending a desktop User-Agent string.

As always, we recommend that you don’t try to detect based on the User Agent string — if you use responsive design and feature detection, your site should just work on Continuum. However, for some cases, including analytics or to provide a specifically tailored experience, developers may wish to detect when Microsoft Edge is running in Continuum.

In Continuum, Microsoft Edge changes a few tokens to make sure it gets desktop markup:

Microsoft Edge UA (Mobile)

Mozilla/5.0 (Windows Phone 10.0; Android 6.0.1; Microsoft; <Device>) AppleWebKit/<Rev (KHTML, like Gecko) Chrome/<Rev> Mobile Safari/<Rev> Edge/<Rev>

Microsoft Edge UA (Continuum)

Mozilla/5.0 (Windows NT 10.0; ARM) AppleWebKit/<Rev> (KHTML, like Gecko) Chrome/<Rev> Safari/<Rev> Edge/<Rev>

Microsoft Edge UA (Desktop)

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/<Rev> (KHTML, like Gecko) Chrome/<Rev> Safari/<Rev> Edge/<Rev>

The revision numbers will, as in all browsers, change regularly as Microsoft Edge is updated, to ensure modern markup is received.

Independent scroll

Running desktop sites on phone is challenging, so we’ve made optimizations in the Anniversary Update to tailor performance to provide a more desktop-like experience. On PCs, Microsoft Edge offloads scrolling from the UI thread to provide a more fluid scrolling experience during page load/painting. In the Anniversary Update, this same feature is now supported in Continuum, even when scrolling via the mouse or keyboard. This results in a smoother experience even while the page is loading or painting.

Switching from mobile to desktop

Microsoft Edge will recognize when a phone switches into Continuum and any sites opened after the switch will render using desktop behavior, including the desktop UA string.

If a tab is open to a mobile site, and the device switches to Continuum, the tab will be sustained. If the tab is refreshed, and it isn’t a mobile-specific URL, it will reload in a desktop view. This ensures that users do not lose unsaved changes (such as a partially-filled form) on a site while switching from the phone to Continuum.

We’re committed to making Continuum as close to the desktop experience as possible without adding any additional overhead for Web Developers – try it out on a Windows 10 Mobile device and let us know what you think! If you have questions or are curious how your site looks in Continuum, reach out to @MSEdgeDev on Twitter, and we’d be happy to help.

Balaji Bhaskar, Program Manager, Microsoft Edge

Building a more power efficient browser

Today, Jason Weber shared a post on the Windows Experience Blog demonstrating the power efficiency of Microsoft Edge over other popular browsers on Windows 10. With the Windows 10 Anniversary Update, we are hard at work pushing the envelope further, engineering Microsoft Edge to last even longer with typical workloads.

In this post, I’ll share our approach to the complex problems of battery life and power consumption, and discuss some specific work we’re doing to improve Microsoft Edge’s energy efficiency in the Windows 10 Anniversary Update.

How we measure energy efficiency

Improving energy efficiency starts in a controlled lab environment where we can run repeatable tests. At Microsoft, we have a lab specifically designed for measuring power consumption, where we run the newest builds of Windows 10 and Microsoft Edge. This allows us to see how they perform against different workloads and with different PCs.

Photo of a power consumption lab at Microsoft. Rows of PCs, phones, and more are shown hooked up to power consumption monitoring equipment.

Power consumption lab at Microsoft

We measure power consumption across a diverse set of Windows hardware – desktops, laptops, tablets, phones and more. Process architectures, screen sizes, and even physical characteristics like heat dissipation and mechanical fans can have a significant impact on power consumption. It’s important to broadly improve power efficiency for everyone.

Machines such as the below Surface Pro 3 are connected to specialized power monitors which measure instantaneous power consumption down to the milliwatt. As we run different workloads across these machines, we measure exactly how much energy they consume.

Photo of a Surface Pro 3 attached to instantaneous power consumption equipment.

Surface Pro 3 instrumented to measure instantaneous power consumption. We test power efficiency on a variety of devices, including Surface Pro 3, Surface Pro 4, and Surface Book.

We also record detailed diagnostic information through Windows Event Tracing, which allows us to understand what was happening in software, and correlate that to the energy consumed by the machine – specifically Microsoft Edge and the website’s HTML, CSS, and JavaScript.

The lab provides repeatable and immediately actionable results in a controlled environment. This allows us to validate improvements, identify regressions, and ensure that Windows and Microsoft Edge are continuously improving with every code change.

Informing power efficiency through customer telemetry

Our objective is to improve efficiency for users, and it’s important to understand what’s happening in the real-world. The Windows Energy Estimation Engine (E3) is a service running on all battery powered Windows 10 devices which tracks energy usage across hardware, apps, and services. The E3 service provides users with more control over their battery life by informing battery saver recommendations, and aggregated results are used by Microsoft through the Windows telemetry systems to improve the Windows ecosystem.

Many modern Windows computers, such as the Surface family, include specialized hardware designed to measure power consumption. This specialized hardware measurement provides 98% accuracy, compared to system software power measurement which has 85% accuracy, and application software power measurement which has minimal correlation to actual power consumption.

Some of our most important insights come from aggregated data from millions of Windows devices reporting billions of data points around Microsoft Edge’s energy efficiency to Microsoft on a monthly basis. We particularly pay attention to telemetry coming from systems with specialized hardware measurement – you just can’t beat 98% accuracy.

Have you ever wondered how many joules of energy are spent on JavaScript garbage collections every day? Those are the multifaceted questions we consider as we optimize Microsoft Edge for performance, power, memory, and more. With this level of data, the tradeoffs around power become clear and intentional.

Screen capture showing a view of aggregated data reporting power consumptions across typical JavaScript operations.

With every Windows Insider flight, we compare our power consumption with past flights and released versions of Windows. We use this telemetry to ensure new features and code changes don’t increase our power consumption, and to validate new features designed to improve energy efficiency. Thanks to the Windows Insider Program, we can validate our engineering and ensure Microsoft Edge only improves with every release!

Energy efficiency improvements in the Windows 10 Anniversary Update

The Windows 10 Anniversary Update brings dozens of improvements to power efficiency, informed from analyzing customer telemetry and experiments in our controlled labs. These improvements are built into Microsoft Edge, so you don’t need to change settings or turn on a power saving mode – every Microsoft Edge user will receive these without a compromised experience.

Here are four examples which provide a feel for the type of power optimizations occurring.

1. Background tabs are more efficient

Websites frequently run JavaScript in the background, even once fully loaded and not visible to the user. These sites may be checking for new email, analyzing ad metrics, running animations, or anything really – the web is a diverse place. So, when a user has a lot of background tabs open at once, these tasks add up, causing the CPU to work more than it needs to. This makes the computer slower and consumes unnecessary battery life. We’ve heard feedback from our Insiders telling us that sometimes Microsoft Edge is using more CPU than they expect, and background tabs are frequently the cause.

With the Anniversary Update, Microsoft Edge only executes background JavaScript timers once per second in background tabs. More importantly, these timers are coalesced with other work happening across Windows. Microsoft Edge doesn’t wake up the hardware to perform work. Instead we tag along with other work happening across the system, and then quickly yield, allowing the hardware to enter a low power state.

Savings vary depending on the websites you have open, but we’ve seen energy savings of over 90% in some scenarios.

This balance allows your background tabs to keep connections to servers open, check for mail, play music, run analytics, and whatever else they need to do, and also makes your system faster while saving your battery.

Savings vary depending on the websites you have open, but we’ve seen energy savings of over 90% in some scenarios. As an example, the following charts show CPU improvements with eight popular websites open in background tabs.

Charts showing CPU utilization in Windows 10 and the Anniversary Update.

CPU usage with eight popular websites open in background tabs.

2. Flash is more efficient

Flash ads are common on the Internet and they can have a high battery cost, primarily through continuous animations which continually consume CPU, GPU and display resources. In the Anniversary Update, Flash is now running inside a separate process, and controls which aren’t central to the page are paused by default. Users who want to interact with Flash can simply click the control.

And given Flash is now running in a separate process, we can monitor and control the resource impact of Flash. When Flash consumes too many resources or crashes, we can stop the Flash process without impacting the website.

3. Microsoft Edge’s user interface is more efficient

The Microsoft Edge user interface has been optimized for power efficiency. Animations are an important part of the Windows 10 and Microsoft Edge design language, but animations can consume considerable power if they perform more work than necessary.

For example, the reading mode button animation has been redesigned around power efficiency.

Screen capture of the Reading Mode button in Microsoft Edge

The reading mode button was previously composed of 120 frames. Each time we updated the frame, we caused an expensive XAML layout and visual update. Here we can see the GPU cost for this one animation:

Screen capture showing the GPU cost of the Reading Mode animation

GPU cost of the Reading Mode animation

We have improved this in several ways.

  • The animation had identical frames at the beginning and end of each loop, so progressing frames didn’t always result in visible changes. Optimizing this removed 40% of the frames.
  • We replaced the traditional XAML animation with a timed GPU transform, and now animate the contents through a viewport – relying entirely on the GPU to perform the work.
  • These coupled with other optimized have reduced the GPU cost by nearly 75%, the CPU cost by 100%, and reduced the power impact to near zero.

Here’s the GPU cost of this animation with the Anniversary Update:

Screen capture showing the GPU cost of the Reading Mode animation in the Windows 10 Anniversary Update

GPU cost of the Reading Mode animation in the Windows 10 Anniversary Update

That looks much better! We’re applying this level of optimization across our user interface, because every milliwatt counts.

4. Windows networking is more efficient

Microsoft Edge builds on the Windows platform, and benefits from power optimizations throughout Windows. The Windows 10 Anniversary update delivers a range of networking improvements which improve performance and efficiency, while reducing power consumption.

The new TCP Fast Open (TFO) feature allows connections between the device and the server to be setup faster with fewer messages. And the TCP stack now includes an optimized Initial Congestion Window (ICW) with a larger maximum message size, meaning fewer messages have to be exchanged with the server. Fewer messages means the wifi antenna can be turned off sooner, saving energy.

We’ve also added features called Tail Loss Probe (TLP) and Recent Acknowledgement (RACK) which reduce the time required to correct for lost packets. If it’s likely that a message is going to time out, we send a request for the data again sooner than the normal timeout. Doing this allows us to switch off the wifi antenna sooner when you have a poor connection.

What’s next?

Are we done? Absolutely not!  When it comes to energy efficiency, we’re never really done, and you’ll continue to see this level of investment over the coming releases. You can preview these improvements today in the Windows Insider Program, and we look forward to bringing them to everyone with the Windows 10 Anniversary Update this summer.

Brandon Heenan
Program Manager, Microsoft Edge

Managing Microsoft Edge in the enterprise

At last year’s Microsoft Ignite conference, we introduced the enterprise story for the web on Windows 10. Microsoft Edge is designed from the ground up to provide a modern, interoperable, and secure browsing experience; in addition, Internet Explorer 11 is also a part of Windows 10 to help bring all your legacy line of business (LOB) applications forward.

Microsoft Edge and Internet Explorer 11 work together to help ease IT management overhead, and also provide a seamless user experience for your users. In this post, we’ll walk through the policies you can use to manage Microsoft Edge in the enterprise for both PCs and mobile devices, including some new policies coming in the Windows 10 Anniversary Update.

Policies currently supported in Microsoft Edge

With Microsoft Edge, we set out to provide a simple, consistent set of scenario-driven management policies to help manage Windows 10 browser deployments on both desktop and mobile. The policies for Microsoft Edge on desktop are available as both Group Policy settings and MDM settings. On mobile they are available as MDM settings.

Here is a summary of all the policies supported by Microsoft Edge grouped by Windows 10 releases:

  • Available in Windows 10 version 1507 or later:
    • Configure Autofill
    • Configure Cookies
    • Configure Do Not Track
    • Configure Password Manager
    • Configure Pop up Blocker
    • Configure search suggestions in the Address bar
    • Configure the Enterprise Mode Site List
    • Configure the SmartScreen Filter
    • Send all intranet sites to Internet Explorer 11
  • Available in Windows 10 version 1511 or later:
    • Allow Developer Tools
    • Allow InPrivate browsing
    • Allow web content on New Tab page
    • Configure Favorites
    • Configure Home pages (see additional note below)
    • Prevent bypassing SmartScreen prompts for files
    • Prevent bypassing SmartScreen prompts for sites
    • Prevent sharing LocalHost IP address for WebRTC

What’s new in Windows 10 Anniversary update

We have added support for the following new Microsoft Edge management policies as a part of the Windows 10 Anniversary Update:

  • Allow access to the about:flags page
  • Allow usage of extensions
  • Configure WebRTC media port ranges
  • Show a transitional message when opening Internet Explorer sites

We’ve made a few updates to existing policies based on feedback from customers.  First, all of the Microsoft Edge Group Policy settings on desktop are now available in both the User and Machine policy hives. Second, the home page policy configured on a domain-joined device will no longer allow the user to override the setting.

You can find further details on all Microsoft Edge policies on TechNet, including info about Windows 10 policies that also apply to Microsoft Edge, such as Cortana and Sync settings. Your feedback is important to us, so please let us know what you think or if you have any questions about these changes!

– Dalen Abraham, Principal Program Manager Lead
– Jatinder Mann, Senior Program Manager Lead
– Josh Rennert, Program Manager