Re: Add API for a kiosk app to shutdown/reboot a ChromeOS device

[Benjamin Kalman]

extensions-dev --> apps-dev.

Sounds reasonable with a sensible browser-implemented UI. Or, what Jeffrey says.

On Mon, Sep 30, 2013 at 12:57 PM, Xiyuan Xia <xiy...@chromium.org> wrote:

A kiosk app running on a ChromeOS device needs to be able to shutdown/restart the device. Current there is no way for the kiosk app to do that.

How about adding chrome.runtime.shutdown/reboot to provide such functionality?

Thanks

Xiyuan

--
You received this message because you are subscribed to the Google Groups "extensions-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to extensions-de...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/groups/opt_out.

[Benjamin Kalman]

Which was:

"If a kiosk app closes its last open window and returns from all

scripts, what happens? I'd expect it to make the machine unusable, so
maybe that would be a good indicator to reboot."

[Benjamin Kalman]

On Mon, Sep 30, 2013 at 1:06 PM, Zelidrag Hornung <zeli...@chromium.org> wrote:

+achuith

Achuith might have added such API (private) for test automation purposes already.

On Mon, Sep 30, 2013 at 1:05 PM, Zelidrag Hornung <zeli...@google.com> wrote:

+achuith

Achuith might have added such API (private) for test automation purposes already.

On Mon, Sep 30, 2013 at 1:02 PM, Joe Marini <joem...@google.com> wrote:

I assume that it would be limited to apps that request kiosk permission and are the current kiosk app?

On Mon, Sep 30, 2013 at 12:57 PM, Xiyuan Xia <xiy...@chromium.org> wrote:

A kiosk app running on a ChromeOS device needs to be able to shutdown/restart the device. Current there is no way for the kiosk app to do that.

How about adding chrome.runtime.shutdown/reboot to provide such functionality?

Thanks

Xiyuan

--
You received this message because you are subscribed to the Google Groups "extensions-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to extensions-de...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/groups/opt_out.

--
Joe Marini

Developer Advocate / Chrome

joem...@google.com | +Joe Marini | @joemarini

[Zelidrag Hornung]

Yes, the kiosk session will indeed be restarted when the app closes all its open pages (incl. background page). The system will also reboot at that point if it has a good reason for that (i.e. pending AU).

Xiyuan, why do you think we still need an explicit API for this purpose?

[Xiyuan Xia]

Yes, the current behavior is to shutdown the current session when the last app window is closed. And if there is a pending AU reboot (or uptime limit), the device is rebooted.

The request is from http://crbug.com/287727 where the app wants to have an UI to allow the user to explicitly reboot the device.

[Benjamin Kalman]

In that case can it iterate thorough its open window(s) and close() them, then close() the background page?

[Zelidrag Hornung]

I see your point Xiyuan - the window closing approach might not perform the actual reboot, just restart.

[Benjamin Kalman]

Another strawman: could you show some UI when the app exists? It might not precisely satisfy mocks but neither may the intermediate step of having to confirm shutdown (maybe you don't need the UI if it's tied to a user action... eh). Kiosk-mode only I suppose. FWIW I can think of another use case for a shutdown API; a downloader/whatever which turns off the computer down when it's finished. Kinda niche.

[Zelidrag Hornung]

On Mon, Sep 30, 2013 at 1:43 PM, Benjamin Kalman <kal...@chromium.org> wrote:

Another strawman: could you show some UI when the app exists?

I am not sure that would be a solution that every kiosk app would want. I find this particular use case to be an exception from a generic kiosk usage. The API still seems cleaner.

[Xiyuan Xia]

I am not sure if that is the desired though. In kiosk mode, we let the app handle all the UI and the OS (chrome) provides APIs to support the app. This breaks that principle, because the UI has to be created from the OS where the shutdown/reboot call is available. If we provide API, then the principle is kept and the app can create whatever UI fits.

[Jeffrey Yasskin]

On Mon, Sep 30, 2013 at 1:21 PM, Xiyuan Xia <xiy...@chromium.org> wrote:
> Yes, the current behavior is to shutdown the current session when the last
> app window is closed. And if there is a pending AU reboot (or uptime limit),
> the device is rebooted.
>
> The request is from http://crbug.com/287727 where the app wants to have an
> UI to allow the user to explicitly reboot the device.

The non-kiosk ChomeOS interface doesn't have a reboot button; it only
has a shutdown button. If ChromeOS doesn't need UI to reboot the
device (rather than "sign out", which is equivalent to closing the
last app window), why do kiosk apps need this UI?

"shutdown" might make sense, by this argument, but if users don't have
physical access to the power button on the kiosk, that could let them
wedge it pretty easily.

[Xiyuan Xia]

On Mon, Sep 30, 2013 at 3:06 PM, Jeffrey Yasskin <jyas...@chromium.org> wrote:

The non-kiosk ChomeOS interface doesn't have a reboot button; it only

has a shutdown button. If ChromeOS doesn't need UI to reboot the
device (rather than "sign out", which is equivalent to closing the
last app window), why do kiosk apps need this UI?

Things are a bit different in the kiosk world, where the app the is the only thing a user gets. If anything goes wrong and restart the app does not solve it (e.g. kernel or a daemon has a bug and stops working, out of fd etc), the user would be stuck. Whereas in the regular ChromeOS user session, user could reboot (shutdown and start) to solve the issue.

 

"shutdown" might make sense, by this argument, but if users don't have
physical access to the power button on the kiosk, that could let them
wedge it pretty easily.

This is a good point. In this case, let's stick to just a reboot API as in the bug. 

[Mike Tsao]

<slightly off-topic>

Related concept: watchdog. To the extent kiosks are supposed to act like embedded software, it's always nice to have a failsafe to reboot the machine if the code stops responding. That said, I'm not sure that a Chrome App would do a great job of detecting that it had lost its marbles. I could see someone implementing chrome.runtime.onWatchdogCheck as { return true; }, in which case it would have no effect even if the user had somehow figured out how to close the main window or otherwise reach a UI dead end.

</slightly off-topic>

[Jeffrey Yasskin]

On Mon, Sep 30, 2013 at 3:40 PM, Xiyuan Xia <xiy...@chromium.org> wrote:
> On Mon, Sep 30, 2013 at 3:06 PM, Jeffrey Yasskin <jyas...@chromium.org>
> wrote:
>>
>> The non-kiosk ChomeOS interface doesn't have a reboot button; it only
>> has a shutdown button. If ChromeOS doesn't need UI to reboot the
>> device (rather than "sign out", which is equivalent to closing the
>> last app window), why do kiosk apps need this UI?
>
>
> Things are a bit different in the kiosk world, where the app the is the only
> thing a user gets. If anything goes wrong and restart the app does not solve
> it (e.g. kernel or a daemon has a bug and stops working, out of fd etc), the
> user would be stuck. Whereas in the regular ChromeOS user session, user
> could reboot (shutdown and start) to solve the issue.

'k, sounds like a compelling difference. I guess the last question is
whether "close all windows may just restart" is the right choice. In
kiosk mode, I assume "just restart" is a bit faster, but the kiosk app
also has the option of explicitly returning to their start screen when
the user closes all the windows.

"Close all windows" behavior:
Reboot:
* Pro: developers who do nothing special are insulated from ChromeOS bugs.
* Con: developers who do nothing special take longer to recover from
closing all windows.
* Pro: No need for a kiosk-only API, which could confuse non-kiosk developers
* Con: Maybe the code to detect the last window close and re-run
onLaunched is tricky even for developers who want to do something
special?

Restart-unless-update-or-max-uptime (status quo):
* Pro: lazy developers get faster restarts
* Con: lazy developers give their users no way to recover from ChromeOS bugs
* Con: Need a kiosk-only API

'course, we could make the API not kiosk-only, if we can find good
semantics for it outside of kiosk mode. chrome.runtime.restart() could
reboot all of Chrome in kiosk mode, but only close all windows and
fire onLaunched outside of kiosk mode.

[Zelidrag Hornung]

On Mon, Sep 30, 2013 at 3:56 PM, Jeffrey Yasskin <jyas...@chromium.org> wrote:

On Mon, Sep 30, 2013 at 3:40 PM, Xiyuan Xia <xiy...@chromium.org> wrote:
> On Mon, Sep 30, 2013 at 3:06 PM, Jeffrey Yasskin <jyas...@chromium.org>
> wrote:
>>
>> The non-kiosk ChomeOS interface doesn't have a reboot button; it only
>> has a shutdown button. If ChromeOS doesn't need UI to reboot the
>> device (rather than "sign out", which is equivalent to closing the
>> last app window), why do kiosk apps need this UI?
>
>
> Things are a bit different in the kiosk world, where the app the is the only
> thing a user gets. If anything goes wrong and restart the app does not solve
> it (e.g. kernel or a daemon has a bug and stops working, out of fd etc), the
> user would be stuck. Whereas in the regular ChromeOS user session, user
> could reboot (shutdown and start) to solve the issue.

'k, sounds like a compelling difference. I guess the last question is
whether "close all windows may just restart" is the right choice. In
kiosk mode, I assume "just restart" is a bit faster, but the kiosk app
also has the option of explicitly returning to their start screen when
the user closes all the windows.

Not really. Kiosk app is the UI and the window manager. There are no "windows" controls separated from the app. The restart of a kiosk app happens when all its pages are closed - both background and foreground (which is always a single full screen frameless windows).

 

"Close all windows" behavior:
Reboot:
  * Pro: developers who do nothing special are insulated from ChromeOS bugs.
  * Con: developers who do nothing special take longer to recover from
closing all windows.
  * Pro: No need for a kiosk-only API, which could confuse non-kiosk developers
  * Con: Maybe the code to detect the last window close and re-run
onLaunched is tricky even for developers who want to do something
special?

Restart-unless-update-or-max-uptime (status quo):
  * Pro: lazy developers get faster restarts
  * Con: lazy developers give their users no way to recover from ChromeOS bugs
  * Con: Need a kiosk-only API

The restart in the proposal here is actually needed to bounce the external hardware more than anything else. Chrome(OS) already has its own watchdog mechanisms (both kernel and userspace/UI) for detecting when it's hung.

[Xiyuan Xia]

Jeffrey, There is an existing API chrome.runtime.reload that does something very close to what you describe for non-kiosk app. How about make it reboot the device when in kiosk mode?

Achuith, thanks for the pointer. But autotestPrivate seems dealing with chrome only, i.e. shutdown/restart refers to chrome's shutdown and restart. Here we want to reboot the device. 

On Mon, Sep 30, 2013 at 5:47 PM, Achuith Bhandarkar <ach...@google.com> wrote:

The api we currently have is autotestPrivate.restart and autotestPrivate.shutdown.

https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/extensions/api/autotest_private/autotest_private_api.h&l=25-42

This is as yet unused by autotests. I can move this to chrome.runtime - feel free to file a bug and assign to me.

[Jeffrey Yasskin]

On Mon, Sep 30, 2013 at 7:11 PM, Xiyuan Xia <xiy...@chromium.org> wrote:
> Jeffrey, There is an existing API chrome.runtime.reload that does something
> very close to what you describe for non-kiosk app. How about make it reboot
> the device when in kiosk mode?

I was thinking about suggesting that one, but I believe its behavior
has historically been to reload the app from disk (or reload the code
from the unpacked directory, for unpacked apps, I think), which
doesn't generally happen when the app is relaunched, but would happen
when the device reboots. I don't have any real objections to using
that function if it doesn't complicate the existing code path.

[Bartosz Fabianowski]

Doesn't this turn the API into something really weird, a way to reload
your app in some cases and to reboot in others? It does not seem
particularly clean to have an API that does two such vastly different
things.

- Bartosz

[Xiyuan Xia]

Okay. Then let's have a separate new API chrome.runtime.restart then.

The api should work like this (as suggested by Jeffery):

- In kiosk mode, it reboots the device

- Out of kiosk mode, it closes all the app window and fire onLaunched event again.

Do this sound good?

[Ben Wells]

Can we have it just do nothing out of kiosk mode? That feels better than very different behaviours under dfferent situations (as barfab@ mentioned).

[Xiyuan Xia]

I agree different behavior under the same API might be confusing.

[Xiyuan Xia]

Wrapped up a CL (https://codereview.chromium.org/25944003/) for the proposal. Feel free to comment.

Thanks

[Chanakya]

Hi All,

I created an single kiosk app with navigation controls such as back, forward through chrome app builder.

Through above created single kiosk app, user is unable to shut-down the Chrome OS device(in Kiosk mode).

So,I want provide shut-down button in single kiosk app.

If user click on shut-down button the chrome OS device should be shut-down.

Please any one help me out.

[Chanakya]

Hi All,

I want to allow users to turn off the device via the Shut down icon on the screen,if Chrome device is being run as a kiosk Mode(With single kiosk app).

On Tuesday, October 1, 2013 at 1:36:02 AM UTC+5:30, Benjamin Kalman wrote:

[Xiyuan Xia]

We have discussed about this. And shutdown API is not implemented because we did not find a useful scenario for it. If an end user does not have access to the power button of the device (e.g. a movie ticket booth), the device should not be shutdown. If an end user has access to the power button (e.g. a chromebook based kiosk), then user can just use power button to shutdown the device.

If you don't agree, please provide your reasons. 

[Chanakya]

1.In Single app Kiosk mode the apps are getting crashed when we hard restart the system (Shutting down the system through restart button on CPU) we tried various kiosk apps from web store and all of them are crashing when we do hard restart.

To make crashed app to work we need to install the app again and follow the same steps to enable the kiosk which is time consuming and end users don't know how to make all the required configuration.

In kiosk mode using terminal we rebooted the system and we found that apps are not getting crashed. The apps are getting crashed because of hard Shut down/ Restart of the systems.

[Xiyuan Xia]

Hard shutdown could cause file system corruption and break the system. Sounds like you are using a special hardware which does not have the power button. Could you file a bug on crbug.com? We can move discussion there and see whether this would be something supported.