| Comments

I’ve seen some reports and received some emails on email groups that I’m a part of around Windows 8 and Google Chrome browser and how touch is not working.  In fact I was initially confused about this myself because it was working fine for me on my machine (Lenovo x230t) but other people were insistent that it wasn’t working.  Then I asked what machine they were on.

Almost exclusively everyone was on a “high DPI” machine (or had high DPI settings in their display).  If you have a Surface Pro, for example, you are using a high DPI machine.  I installed Chrome on my Surface Pro and indeed saw the problem there.  After some digging it appears to be that Google Chrome is not yet a high DPI-aware desktop application (at least of this writing which was using version 30.0.1599.66 m – phew that was a mouthful of a version number).

Look at this screenshot.  This is from my Surface Pro with no changes.  I’m tapping on the 2nd image in the news highlights (indicated by the touch square indicator) but notice where the target is actually clicking – on the date “October 4” where the context menu is located:

Chrome missed touch target

I asked around the office and received one workaround, which I received, but also found a better one.  Here are both of them for you to consider.

Workaround 1: run in compatibility mode

This involves you getting to the properties of the chrome.exe program and viewing the compatibility tab.  In there you can check the option to disable DPI scaling:

Chrome compatibility setting

I didn’t like this option because immediately after restarting Chrome the display was crisp but “tiny” to see for my aging eyes.  You can see here is the msn.com site before/after this compatibility setting:

Chrome msn.com before

msn.com on Google Chrome with no compat setting

Chrome msn.com compat set

msn.com on Google Chrome with the compat setting enabled

After this setting the hit-targets are fine and work but the content is small (although admittedly more of it is viewable, but that is too small for me).  To mitigate this you can use Chrome’s zoom feature to zoom to 150% to match most closely the high DPI scaling that automatically happens.

Chrome zoom settings

But there has to be a better way…and is (in my opinion).

Workaround 2: set the Chrome flag for HighDPI Support

I learned that Chrome has “flags” that you can set to experiment with certain settings or override other default/automatic settings.  From the address bar, type “chrome://flags” and you’ll see a page of options.  Scroll near the end and you’ll see a “HighDPI Support Windows” setting which is set to Automatic. 

Chrome HighDPI Flag setting

Force this to Enable and re-launch Chrome.  Boom you are working again.  Simpler fix and gets you scaling on your device as well.  Now some of Chrome’s chrome (menus, etc.) aren’t as crisp still but the main content area doesn’t confuse hit-targeting of your touch interaction because of the scale.

The good part is that it appears that the Chrome team is aware of this and a Chrome bug is logged (Chromium Bug 271222: When using the global Windows UI scaling feature, touchscreen touches are off by the set scale).

I don’t use Chrome on a regular basis (nothing against it, just don’t need it) but do get sad when friends have problems so I like to try to help out.  Hopefully if you are in this case with your touchscreen and Google Chrome this will get you fixed up.

Hope this helps!

| Comments

First a congratulations to the Moonlight team for reaching their official release of 1.0!  Miguel and team have done a great job providing parity with Silverlight 1.0 and should be proud of their accomplishments.  Miguel, when is Moonlight 2 coming out :-) -- no rest!!

But seriously, this is a good accomplishment for the ecosystem.  Last month I wrote and recorded my experience of the Moonlight installer/rendering on an OpenSUSE environment.  What this demonstrated was that we’d integrated the Moonlight redirection/installer into the server-side installer detection from Microsoft.  Users on Linux visiting a Silverlight 1.0 application and not having the plugin would be directed to the Moonlight installer, using the same install link that other Silverlight applications currently leverage.  I think this shows great partnership to both teams to acknowledge and integrate that process.

Today, I updated the user agent detection script for Silverlight to also accommodate this release.  For those who don’t know, there are two helper scripts for Silverlight developers you can leverage:

  • Silverlight.js – this script helps to detect if the plugin is installed and if so, create’s the appropriate <object> tag representation.
  • Silverlight.supportedUserAgent.js – this script is also a helper script that can be used with Silverlight.js or alone.  The purpose of this script is to do some pre-checking to see if the browser/platform combination (based on the reporting User Agent string of the browser) will support Silverlight.

It is the second script that I’m referring to.  The updated release on the release site for the script (2.0.40211.0) now includes checking for Linux and reporting correctly.  Using this script is as simple as:

   1: var canSilverlightRun = Silverlight.supportedUserAgent("2.0");

This code above is basically asking: I’ve got this combination, is this version of Silverlight going to be supported?  This helper can be used by developers to pre-check if Silverlight can run on the platform of the user. 

If you are using the UA detection script, you’ll want to update it to the latest version if you have a Silverlight 1.0 solution and want to expand to Linux users.  That is the only change in this update.  No changes to Silverlight.js have occurred as a result of this, as remember, that only checks if the desired version is installed on the user machine.

If you want to play around with some settings, you can visit a quick-and-dirty page I created that uses both scripts and reports the results (Version Supported reports Silverlight.isInstalled, and UA Supported reports Silverlight.supportedUserAgent).  Hope this may help.

Hey what about this Google Chrome hack you mentioned?

Officially Google Chrome is not a supported browser, but most (your mileage may vary) Silverlight applications run.  Since the detection scripts are Ms-PL licensed, you’re welcome to change them to fit your needs.  The official copy on the release site will map to the supported matrix for Silverlight for now.  If you want to add support for Google Chrome, here’s what you’d do.

On line 93 in Silverlight.supportedUserAgent.js, insert this line:

   1: else if (ua.indexOf('Chrome') >= 0) {
   2:     slua.Browser = 'Chrome';
   3: }

Before the Safari check is important because Chrome’s user agent reports Safari in it as well as Chrome.  Then you will have Chrome detection working in your script.  Again, only if you need/want it.  We continue to evaluate the browser support matrix for Silverlight and before you ask – no decisions have been made just yet to change the current supported matrix.

Hope this helps!  Congratulations Moonlight team!