We are using Google Chrome to publish collections based information and multimedia to the galleries in M Shed using a web application. Here are a few pointers which have helped us get the system up and running

How to run chrome in kiosk mode?

Google Chrome comes with a built in kiosk mode which makes it load up as a full screen browser and without the usual menu bars and features that would normally let you navigate away from or close down the app. There are various ways you can do this, all of which involve tagging on the –kiosk argument to the command that starts Chrome. N.B. don’t try this out this unless you can CRT-ALT-DEL out of it! The script below can be saved as a .bat file in windows, run from the command line, or the extra arguments can be inserted into the proprties of the Chrome icon used to load up the application.

The following batch script loads up chrome in kiosk mode at a specific page:

start “Chrome” chrome file:///C:/Kiosk2014/CaseLayout.htm?KIOSK=LB-DS-ICT02 –kiosk

So far so good, but there are lots of reasons why this alone is not sufficient for the gallery environment. Here are some problems you may run in to, and the workarounds we have found….

1.) Chrome comes with an array of shortcut key combinations that let you access its hidden features, such as the chrome task manager (shift + ESC) and downloads (Crt + J). This means that if your gallery pcs have keyboards then users may be able to hack their way out of chrome and into the PC or off into the web (why a gallery keyboard would have shift and escape keys is beyond me, but ours do). To prevent this problem needs a minimal amount of JavaScript to catch the key press events and convert them to nothing before they are passed to the browser for interpretation. Here’s what is working for us right now:

$(document).keydown(function(e){ //when any key is pressed

if(e.keyCode == 27||e.keyCode ==18) { // if the key is CTRL or ALT

e.preventDefault(); } }); // do nothing

2.) How to run a website saved on the local file system? By default Chrome wont access scripts in files held locally (although Firefox will). Our kiosk applications are all held locally on each machine as a safety precaution in case of network downtime. To overcome the default behaviour in Chrome add the following argument to the startup command above

–allow-file-access-from-files

So the command we now have is:

start “Chrome” chrome file:///C:/Kiosk2014/CaseLayout.htm?KIOSK=LB-DS-ICT02 –kiosk –allow-file-access-from-files

3.) When the machine is rebooted or you force quit chrome, it restarts with the message “Chrome didn’t’ shut down correctly” in a yellow bar at the top of the screen which must be manually closed. This is unsightly for users and likely to be a common occurrence in the gallery environment. To overcome this we pass another parameter to the start command which causes Chrome to start in incognito mode and prevents the message. So our command is now this:

start “Chrome” chrome file:///C:/Kiosk2014/CaseLayout.htm?KIOSK=LB-DS-ICT02 –kiosk –allow-file-access-from-files –incognito

4.) When the web application crashes for whatever reason, there may be no way for a user to reload the page, or for the page to reload itself automatically. There are many different sorts of crashes that can occur, such as the ‘aw snap’ error where Chrome gives an unsmily face and a link to reload the page or navigate away off into the net. Since fixing some bugs and optimising our code we have not seen this error for a while, but we do have a method to return to the web app if something goes wrong. One method is to use windows task scheduler to close and reopen the web app after a set period of time, and handily we already have most of the code for this in the above command. We set the task to be triggered when the computer is idle for 5 minutes, and make the task run the following code – which kills any running chrome process and restarts the app at the right page:

@echo off

taskkill /F /IM chrome.exe /T

start “Chrome” chrome file:///C:/Kiosk2014/CaseLayout.htm?KIOSK=LB-DS-ICT02 –kiosk –allow-file-access-from-files –incognito

Incidentally this is the exact same script we have in our start up folder so that whenever the computer is rebooted, the application starts.

5.) Despite the above, we were still suffering from a ‘grey screen of death’ every once in a while, which loaded the background page in the right colour, but failed to load anything else. This was probably due to the complexity of the application and its various plugins, but it was very undesirable and almost impossible to replicate in our development environment. What was clear was that when the grey screen happened, none of the JavaScript files for the app had been loaded, rendering it useless and stuck. The workaround we have used for this was to bind an onClick event to the document body which forces a page reload, and to remove this event using JavaScript. This means that if the script files fail to load, the page will reload when someone touches it, and chances are everything will be ok, and if everything is ok – the reload click event is removed and the application functions normally.

So, at the top of the document we have this:

<body onClick=”location.reload()”>

and right before the closing body tag we have this:

<script type=”text/javascript”> $(function() { setTimeout(function () { if($(“#VisitorStoriesHelpText”).length>0){ $(‘body’).attr(“onClick”,””) } }, 1 * 1 * 1000);}); </script>

…..actually we haven’t seen the grey screen of death for a while, but a least it is no longer a show stopper.

So in conclusion – Google Chrome can be run in full screen mode as a gallery kiosk application, but it is not plain sailing, and in the gallery environment expect to see strange things happening. We are not out of the woods yet, and the legacy hardware keeps us on our toes, but at least in terms of the web application we can overcome many of the issues that this solution has presented us with.

 

*UPDATE*

We have seen on a number of machines some strange artefacts, pixellation and tearing occurring – when coloured spekles appear, or portions of black screen, in some cases the whole machine becomed unresponsive.  This only happens in the live environment and may be something to do with chrome kiosk mode vs windows 7. To solve this I have added another flag to the chrome command – –disable-gpu. With this added the pixellation goes away, it returns when the flag is removed. Time will tell if this solution holds water, or if it puts too much load on the cpu. We still have room for optimisation (using chrome dev tools) so we should be able to reduce the load if problems persist.