Announcing Windows 10 Insider Preview Build 15051 for Mobile

Hello Windows Insiders!

Today we are excited to be releasing Windows 10 Insider Preview Build 15051 for Mobile to Windows Insiders in the Fast ring.

Other changes, improvements, and fixes for Mobile

  • We appreciate several of you sending us feedback on this and last week, we focused on fixing issues that resulted in frequent reboots for some Insiders on Build 15047. If you continue to experience unexpected reboots, be sure to send in feedback to us via Feedback Hub so the team can take a look!
  • We fixed an issue resulting in certain inbox apps, such as Calculator, Outlook Mail, Outlook Calendar, Groove Music, no longer being present on the system after a hard reset.
  • We fixed an issue resulting in Groove Music not resuming playback after ending a phone call if the app became suspended during the call.
  • We fixed an issue where periodically attaching larger photos to a message in Messaging wouldn’t work.
  • We fixed an issue from recent flights where, in certain apps, if you had selected editable text and pressed Shift on the keyboard, the keyboard would crash.
  • We fixed an issue impacting certain UWP apps using pivots, such as the News app, where the pivot control could end up becoming offset after quickly swiping through the pivots.
  • We fixed an issue where asking Cortana to read a text message over Bluetooth with many back to back emoji would result in high pitched distorted noise.
  • We fixed an issue where after upgrading some Insiders were unexpectedly seeing the full QWERTY keyboard on the lock screen instead of the pin pad.

Known issues for Mobile

  • We have discovered a bug that causes background tasks to not run in the background like they should such as OneDrive’s camera roll sync feature. Please double check your photos have synced to OneDrive on the latest builds. We’ve got a fix for this issue coming in an upcoming build where background tasks will run again and your camera roll will sync to OneDrive as expected.
  • If your device experiences an unexpected reboot, in some cases you may lose your call, text, and email history may be lost. We’re actively investigating this issue. If you believe you’ve hit this, please up-vote this feedback item In Feedback Hub.
  • Speech packs may be unable to download on this build.
  • ADDED: Some users are reporting that pages are constantly reloading or refreshing, especially while they are in the middle of scrolling them in Microsoft Edge. We’re investigating.

Community Updates

We are huge fans of wielding one’s technical superpowers for good and were incredibly happy to meet with Windows Insider Paula Aliu, the CEO of Cogno-Aid in Nigeria. Cogno-Aid is a business that aims to connect people to licensed therapists from the comfort of their safe place, step one of removing the stigma of mental health care.

Paula Aliu, the CEO of Cogno-Aid in Nigeria

Paula was a Computer Science student who was inspired to start this business after losing her college friend to suicide from a mental health disorder that no one was aware existed. Mental health is not something most Nigerians talk about openly. She decided to use her technical superpower to make Nigeria a more healthy place for all with her online business that she’s built using Windows.

We’re so incredibly proud of our global community of Windows Insiders and can’t wait to follow along on Paula’s journey as she launches her business to an even broader audience.

We love hearing your stories so if you have one to share, please get in touch with me on Twitter.

Keep hustling team and happy International Women’s Day,
Dona <3

Dell XPS 13 (9360) 3.5ghz i7 16GB 512GB SSD Infinity Edge QHD+ Touch 3200×1800

I bought this XPS 13 in September and it has been sitting in a box ever since. I used it on the day it was delivered and haven’t needed to again since, so it is in a brand new condition, as you would expect. It has the balance of the 1 year warranty still remaining.

This is the Kaby Lake i7-7500U processor and it has the 3200×1800 InfinityEdge touchscreen display. 16GB RAM and 512GB SSD. The full spec can be found in the uploaded picture.

Price and currency: 1200
Delivery:

Dell XPS 13 (9360) 3.5ghz i7 16GB 512GB SSD Infinity Edge QHD+ Touch 3200×1800

Scythe Big Shuriken, Thermaltake Versa H15 case & Antec Tri Cool Fans

8GB Corsair Vengeance LP 1600mhz DDR 3 – SOLD
AMD FX 8120 – SOLD
Samsung SM841 128gb SSD – SOLD
2x Antec Tri Cool 120mm Fans (These are 3 speed with a switch molex fans) £12 for both.
Asus M5A78L-M/USB3 – SOLD
Scythe Big Shuriken Rev 2 Cooler with Am3 mounting – £20
Thermaltake Versa H15 case – Good little MATX / Mini ATX case with space for 5 fans, very well thought out. – £20 – Collection only.

Price and currency: various
Delivery: Delivery cost is included within my country…

Scythe Big Shuriken, Thermaltake Versa H15 case & Antec Tri Cool Fans

AIO Cooler & Fan Clearout

Got bored which meant I took a trip to Scan. Ended up buying a Swiftech H320 X2 Prestige.

I have the following for sale:

Corsair H100i – perfect secondhand condition, cones with everything as supplied when it was new. This was bought from CCL 06/14. I’ve serviced it today with compressed air. The fans have about 8 hours on them as I bought upgraded fans which turned up a day later £45 inc. Del or £40 pickup – SOLD

2 x Noctua NF-F12 (PWM) £13 inc. Del/each.

1 x Noctua NF-S12A (PWM) £9…

AIO Cooler & Fan Clearout

Pro-Built – High Spec Gaming PC – VR Ready

Tentatively offering my gaming PC for sale. Please don’t ask for splits and spares as I will NOT be splitting.

I had it built by CyberPower Systems last July, purely for VR use (Oculus). It’s based around a
i7-6700K Quad Core 4.00 GHz, and a GTX1080. 16MB Megafury memory, 1TB SSD.

Full Spec sheet below, as per my receipt from CyberPower Systems.

Infinity X77 Pro

CAS: NZXT Source 220 Mid-Tower Gaming Case w/ Window Side Panel USB
3.0 Black [-18] (Black colour)…

Pro-Built – High Spec Gaming PC – VR Ready

16GB (2 x 8GB) DDR3 ECC Unbuffered Memory (Gen8 Microserver)

I’m looking for 16GB DDR3 memory (needs to be 2 x 8GB) for my Gen8 HP Microserver. Needs to be ECC unbuffered. Please let me know what you have! Thanks.

Location: London

______________________________________________________
This message is automatically inserted in all classifieds forum threads.
By replying to this thread you agree to abide by the trading rules detailed here.
Please be advised, all…

16GB (2 x 8GB) DDR3 ECC Unbuffered Memory (Gen8 Microserver)

Scrolling on the web: A primer

Scrolling is one of the oldest interactions on the web. Long before we had pull-to-refresh or infinite-loading lists, the humble scrollbar solved the web’s original scaling problem: how can we interact with content that’s stretched beyond the available viewport?

Animations by Rachel Nabors

Today, scrolling is still the most fundamental interaction on the web, and perhaps the most misunderstood. For instance, do you know the difference between the following scenarios?

  • User scrolls with two fingers on a touch pad
  • User scrolls with one finger on a touch screen
  • User scrolls with a mouse wheel on a physical mouse
  • User clicks the sidebar and drags it up and down
  • User presses up, down, PageUp, PageDown, or spacebar keys on a keyboard

If you ask the average web user (or even the average web developer!) they might tell you that these interactions are all equivalent. The truth is far more interesting.

As it turns out, all five of these input methods have vastly different characteristics, especially when it comes to performance and cross-browser behavior. Some of them (such as touch screen scrolling) are likely to be smooth even on a page with heavy JavaScript usage, whereas others (such as keyboard scrolling) will make the same page feel laggy and unresponsive. Furthermore, some kinds of scrolling can be slowed down by DOM event handlers, whereas others won’t. What’s going on here?

To answer that question, and to understand how to unlock the smoothest-possible scrolling on your website, let’s take a step back and understand how browsers deal with multithreading and input.

The multithreaded web

Conceptually, the web is a single-threaded environment. JavaScript blocks the DOM, and the DOM blocks JavaScript, because both are fighting over the same thread – frequently referred to as the “main thread” or “UI thread.”

For instance, if you were to add this (horrible) JavaScript snippet to your page, you’d immediately see jankiness across the entire user experience:

setInterval(() =&amp;gt; {
  var start = Date.now();
  while (Date.now() - start &amp;lt; 500) {/* wheeeee! */}
}, 1000);

While this JavaScript is spinning in a useless loop, buttons don’t work, form elements are unresponsive, and even animated GIFs grind to a halt – for all intents and purposes, the page is frozen. You can see this in action in a simple demo.

Furthermore, if you try to scroll with the keyboard up/down arrows, the page remains predictably stuck until the JavaScript stops running. All of this is strong evidence for our view of the web as a single-threaded environment.

There’s a curious anomaly, though: if you try to scroll using touch screen scrolling, the page happily moves up and down, even while JavaScript is blocking nearly everything else on the page. This also works for touch pad scrolling, mouse wheel scrolling, and click-and-drag scrolling (depending on your browser).

Somehow, certain scroll actions can manipulate the page state, even while everything else – buttons, input, GIFs – are totally frozen. How can we square this with our theory of the single-threaded web?

A tale of two threads

As it turns out, the whole “browsers are single-threaded” story is largely true, but there are important exceptions. Scrolling, in all its various flavors, is one of those exceptions.

Over the years, browser vendors have recognized that offloading work to background threads can yield enormous improvements to smoothness and responsiveness. Scrolling, being so important to the core user experience of every browser, was quickly identified as a ripe target for such optimizations. Nowadays, every major browser engine (Blink, EdgeHTML, Gecko, WebKit) supports off-main-thread scrolling to one degree or another (with Firefox being the most recent member of the club, as of Firefox 46).

With off-thread scrolling, even a noisy page will appear smooth as you scroll through it, because all scrolling is handled on a separate thread. It’s only when you try to interact with the page through some non-scrolling mechanism – tapping a button, typing into an input, clicking a link – that the façade fades away and the parlor trick is revealed for what it is. (Considering how well it works, though, it’s a great trick!)

There is a tradeoff with asynchronous scrolling, however, which is a common effect called checkerboarding, so named because of the way it originally appeared on Safari for iOS (as gray-and-white checkers). In most modern browsers, it manifests as a blank space that appears when you’ve scrolled faster than the browser can paint. This isn’t perfect, but it’s a worthy tradeoff compared to blocked, jerky, or unresponsive scrolling.

Unfortunately, it’s not always easy to move scrolling to a background thread. Browsers can only do this if the host operating system allows for concurrent input, and it can vary from device to device. In particular, keyboard input is not as optimized as input from mouse or touch devices, ultimately leading to laggier keyboard scrolling across browsers.

A little history is instructive here. When operating systems like Windows and macOS were first designed, one thread was all you got, and so there was little foresight to allow for concurrent input. It was only when multi-core machines started to appear that OSes began to retro-fit concurrency into their design.

So, in the same way that vestigial organs can reveal an animal’s evolutionary history, the single-threaded origin of operating systems starts to peek through the seams when you look at scrolling input across the web. It’s only if the host operating system allows for concurrent input – from a mouse, keyboard, or other device – that browsers can efficiently optimize scrolling to be unaffected by long-running JavaScript operations that hog the main thread.

On the Microsoft Edge team, though, we’ve been making strides to ensure that scrolling remains smooth and responsive, regardless of the scrolling method you prefer. As of EdgeHTML 14 (which shipped in the Windows 10 Anniversary Update), we support off-thread scrolling for the following input methods:

  • Single-finger, touchscreen
  • Two-finger, touchpad
  • Mouse wheel
  • Sidebar

If you compare Edge to other desktop browsers, you’ll find that it’s the only one to support asynchronous sidebar scrolling  – i.e. clicking-and-dragging the scroll handle, or clicking on the trackbar or arrows. (In fact, this is a feature we quietly introduced in the Anniversary Update!)

Testing on Windows 10 (14393, Surface Book) and macOS Sierra (10.12, MacBook Air), we can derive the following results:

Two-finger trackpad Touch Mouse wheel Sidebar Keyboard
Edge 14 (Windows) Y Y Y Y N
Chrome 56 (Windows) Y Y Y N N
Firefox 51 (Windows) N N N N N
Chrome 56 (MacOS) Y N/A Y N N
Firefox 51 (MacOS) Y N/A Y N N
Safari 10.1 (MacOS) Y N/A Y N N

As this table demonstrates, scrolling performance can vary dramatically from browser to browser, and even from OS to OS. If you’re only testing on one browser with one scrolling method, then you might be getting a very narrow view of your site’s performance as it’s actually experienced by users!

Overall, though, it should be clear that scrolling has a special place on the web, and browsers have worked very hard to make sure that scrolling is snappy and responsive. However, there are subtle ways that a web developer can inadvertently disable a browser’s built-in optimizations. Let’s take a look at how web developers can influence browser scrolling, for good and bad.

How event listeners interfere with scrolling

Off-thread scrolling represents a great gain in efficiency – scrolling and JavaScript are completely decoupled, allowing them to work in parallel without blocking each other.

Anyone who’s been building web pages for a while, though, probably knows how to introduce a choke point between JavaScript and scrolling:

window.addEventListener(“wheel”, function (e) {
  e.preventDefault(); // oh no you don’t!
});

When we attach a “wheel” listener that calls event.preventDevault(), it will 100% block scrolling, regardless of the input method. And obviously, if scrolling is blocked, then off-thread scrolling is also blocked.

What’s less obvious, though, is the impact in this case:

window.addEventListener(“wheel”, function (e) {
  console.log(‘wheel!’);
  // innocent listener, not calling preventDefault()
});

You might naïvely think that a function that doesn’t call preventDefault() can’t block scrolling at all, or that, at the very worst, it can only block for the duration of the function itself. The truth, however, is that even an empty listener will totally block scrolling until any JavaScript operation on the page has finished, which you can verify with this demo.

Even though the wheel listener has nothing to do with our big blocking JavaScript operation, they share the same JavaScript event loop, and so the background thread must wait for the longer JavaScript operation to finish before it can get a response from the listener function.

Why does it have to wait? Well, JavaScript is a dynamic language, and the browser can’t know for sure that preventDefault() will never get called. Even if it’s obvious to the developer that the function is just doing a simple console.log(), browser vendors have opted not to take any chances. In fact, even an empty function() {} will exhibit this behavior.

Note that this applies to more than just “wheel” events: on touchscreen devices, scrolling can also be blocked by “touchstart”, “touchend”, or “touchmove” listeners. One should be very careful when adding listeners to a page, because of this impact on performance!

There are a few scroll-related JavaScript APIs, however, that don’t block scrolling. The “scroll” event, somewhat counterintuitively, can’t block scrolling because it fires after the scroll event, and thus it isn’t cancelable. Also, the new Pointer Events API, which was pioneered in IE and Microsoft Edge and has recently started to appear in Chrome and Firefox, has an explicit design goal to avoid unintentional scroll-blocking.

Even in cases where we absolutely need to listen to “wheel” or “touchstart” events, there are certain tricks that web developers can employ to ensure that scrolling remains on the fast path. Let’s take a look at a few of these tricks.

Global vs local event listeners

In the example above, we covered the case of global listeners (i.e. listeners attached to the “window” or “document”). But what about listeners on individually scrolling elements?

In other words, imagine page that is scrollable, but there is also a subsection of the page that itself is independently scrollable. Will the browser block the entire page’s scrolling if you only attach a listener to the scrollable subsection?

document.getElementById(‘scrollableDiv’)
.addEventListener(“wheel”, function (e) {
  // In theory, I can only block scrolling on the div itself!
});

If you test this out using a simple demo page, you’ll find that both Microsoft Edge and Safari will allow the document to scroll smoothly, even if there’s a scroll listener on the scrollable div, and the page has heavy JavaScript operations running.

Here is a chart of the browsers and their behaviors:

Two-finger touchpad Touch Mouse wheel Click-and-drag Keyboard
Edge 14 Desktop (Windows) Y Y Y Y N
Chrome 56 Desktop (Windows) N Y N N N
Firefox 51 Desktop (Windows) N N N N N
Chrome 56 Desktop (MacOS) N N/A N N N
Firefox 51 Desktop (MacOS) Y N/A Y N N
Safari 10.1 (MacOS) Y N/A Y N N

 

These results show that there’s a potential optimization that web developers can employ to take advantage of these browser features. Instead of attaching wheel/touch listeners to the entire document, it’s preferable to add listeners to a targeted subsection of the document, so that scrolling can remain smooth for unaffected parts of the page. In other words, rather than delegating wheel/touchstart listeners to the highest-possible level, it’s best to keep them isolated to the element that needs the scroll event.

Sadly, not all JavaScript frameworks follow this practice – in particular, React tends to add global listeners to the entire document even if it should only apply to a subsection of the page. However, there is an open issue for this very problem, and the React folks have said they would be happy to accept a pull request. (Kudos to the React folks for being so receptive when we provided this feedback!)

Passive event listeners

Avoiding global listeners for wheel/touchstart is a good practice, but sometimes it just isn’t possible, depending on the effect you’re trying to achieve. And in a way, it may feel silly that a simple event listener should force the browser to halt the world, just on the offchance that it might call preventDefault().

Luckily there is a new feature that is just starting to appear in browsers, where web developers can explicitly mark a listener as “passive” and thus avoid waiting:

window.addEventListener(“wheel”, function (e) {
  // Not calling preventDefault()!
}, { passive: true } // I pinkie-swear I won't call preventDefault()
);

With this fix in place, the browser will treat scrolling exactly as if the “wheel” listener had never been added. This feature is already available in the latest versions of Chrome, Firefox, and Safari, and should appear soon in an upcoming release of Microsoft Edge. (Note: you will need to use feature detection to support browsers that don’t have passive event listeners.)

For some events (notably “touchstart,” “touchmove,” and “touchend”) Chrome has also opted for an intervention in version 56 to make them passive by default. Be aware of these subtle browser differences when you add event listeners!

Conclusion

As we’ve seen, scrolling on the web is a fantastically complicated process, and all the browsers are at various stages of improving their performance. In general, though, we can land on some solid pieces of advice for web developers.

First off, it’s best to avoid attaching wheel or touch listeners to the global document or window objects, and instead add them to smaller scrollable elements. Developers should also use passive event listeners whenever possible, with feature detection to avoid compatibility issues. Using Pointer Events (there is a polyfill) and “scroll” listeners are also surefire ways to prevent unintentional scroll-blocking.

Hopefully this post has provided some helpful guidance for web developers, as well as a peek into how browsers work under the covers. No doubt, as browsers evolve and the web continues to grow, scrolling mechanics will become even more complex and sophisticated.

On the Microsoft Edge team, we’re excited to keep innovating in this space and to provide smoother scrolling for more websites and more users. Let’s hear it for the humble scrollbar, the oldest and most nuanced interaction on the web!

Nolan Lawson, Program Manager, Microsoft Edge