UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.89 Safari/537.36
Platform: 8350.68.0 (Official Build) stable-channel veyron_mickey

Steps to reproduce the problem:
1. Auto-launch kiosk app (that makes use of chrome.fileSystem.requestFileSystem method) in managed chrome device
2. Plug/unplug keyboard and mouse while app is launching

What is the expected behavior?
According to the docs, the requestFileSystem API is available to kiosk apps running in kiosk session.  For manual-launch kiosk mode, a confirmation dialog will be shown on top of the active app window.  However, if the app is in auto-launch kiosk mode the confirmation dialog should never be shown.

https://developer.chrome.com/apps/fileSystem#method-requestFileSystem

What went wrong?
When launching the app on a managed Chrome device (ASUS Chromebit) that has been configured to auto-launch through Chrome Device Management, the confirmation dialog is still sometimes shown.  This prevents the app from launching and renders the device useless until a user clicks "Allow" on the dialog, which shouldn't happen in an auto-launched kiosk app.

WebStore page: 

Did this work before? N/A 

Chrome version:  52.0.2743.116  Channel: stable
OS Version:  52.0.2743.116.
Flash Version: Shockwave Flash 23.0 r0

First reported on the Google for Work Connect discussion forums here: 

https://connect.googleforwork.com/thread/17478

I have a Chrome kiosk app that uses the fileSystem API to store its configuration.  According to the API documentation for the chrome.fileSystem.requestFileSystem method, a confirmation dialog will be shown on top of the active app window only in "manual-launch kiosk mode."  However, I'm seeing this confirmation dialog sometimes when the app is in "auto-launched" kiosk mode (i.e., it's running on a managed Chrome device that has been set to auto-launch my app through Chrome Device Management).

I'm familiar with this confirmation dialog, as I have seen it every time I've launched the app manually from the "Apps" tab on the Chrome login screen.  A picture of the dialog is included as an attachment.

I'm using the fileSystem API to request a file system every time the app launches:

    chrome.fileSystem.getVolumeList(function(volumes) {  
      var id;  
      if (chrome.runtime.lastError) {  
        console.error('getVolumeList: ' + chrome.runtime.lastError.message);  
        return;  
      }  
      id = volumes[0].volumeId;  
      chrome.fileSystem.requestFileSystem({  
        volumeId: id,  
        writable: true  
      }, function(fs) {  
        if (chrome.runtime.lastError) {  
          console.error('requestFileSystem: ' + chrome.runtime.lastError.message);  
          return;  
        }  
        onInitFileSystem(fs);  
      });  
    });  

I believe it's the call to chrome.fileSystem.requestFileSystem that causes the dialog to be shown.

Here's the fileSystem section from my manifest:

    { "fileSystem":
      ["write", "retainEntries", "directory", "requestFileSystem"]
    },

I've been able to intermittently reproduce this bug on my managed Chromebit by unplugging/replugging the mouse and keyboard into the Chromebit while the app is starting up.  I first saw this bug when I unplugged the keyboard/mouse as the app was starting up, but this was after multiple reports from customers that they had seen this dialog on their managed Chrome devices that were set to auto-launch.  They're reported it on Chromebit and Chromebox devices.

What would cause the dialog to appear when the app is auto-launched?  Could the app be mistakenly registering with the OS as an app in "manual-launch kiosk mode"?  Perhaps unplugging or plugging in the keyboard tricks the OS into thinking the app has been launched manually by a user?

I've also included device logs from CDM from after the error occurred (I'd estimate the dialog error occurred around 12:30pm in those logs).

Any help is greatly appreciate.
 

Deleted: IMG_3401.jpg 1.7 MB

	IMG_3401.jpg 1.7 MB View Download

Deleted: logs_20160913-1010.zip 475 KB

logs_20160913-1010.zip 475 KB Download