Proposal: JavaScript API call to enable access to special keys.

[Nick Austin]

I'm running a Chrome OS netbook and ran into the issue that Ctrl-W
does not work for web apps.

The best approach we've come up with for this problem is to add a
function to the JS API which allows web apps to request the use of
special keys.

This is related to these bugs:
http://code.google.com/p/chromium/issues/detail?id=5496 (Figure out
how to deal with sluggish renderers blocking accelerators)
http://code.google.com/p/chromium/issues/detail?id=32787 (keydown
event not fired for ctrl-w, ctrl-n, ctrl-t)

Thoughts?

[Peter Kasting]

On Wed, Mar 30, 2011 at 10:34 AM, Nick Austin <nick....@gmail.com> wrote:

The best approach we've come up with for this problem is to add a
function to the JS API which allows web apps to request the use of
special keys.

I'm concerned about allowing malicious pages to use this API to make it hard to escape from them.  After all, the original reasons for our behavior here centered around badly-behaved pages and renderers.

PK 

[Caleb Eggensperger]

I thought the original reason was hung renderers, not malicious pages.
At any rate, I think the idea was to make the user explicitly approve
of this (either through a permission requested by the app/extension or
through an infobar). Also, the user could always use the close button.

> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>

--
Caleb Eggensperger
www.calebegg.com

[Peter Kasting]

On Wed, Mar 30, 2011 at 10:45 AM, Caleb Eggensperger <cale...@gmail.com> wrote:

I thought the original reason was hung renderers, not malicious pages.

Hung renderers was a primary problem, but malicious apps were also discussed, and even if they hadn't been they'd be in scope here anyway.

Also, the user could always use the close button.

UI can never rely on the mouse as the sole way of doing something.

PK

[Nick Austin]

On Mar 30, 10:49 am, Peter Kasting <pkast...@google.com> wrote:

> On Wed, Mar 30, 2011 at 10:45 AM, Caleb Eggensperger <caleb...@gmail.com>wrote:
>
> > I thought the original reason was hung renderers, not malicious pages.
>
> Hung renderers was a primary problem, but malicious apps were also
> discussed, and even if they hadn't been they'd be in scope here anyway.

A malicious site can already use onclose to better effect.
We could prompt the user (like the location permission dialog) if this
is a real problem.

[James Su]

I'd actually prefer to remove ctrl-[a-z] from reserved accelerator list and give them to web pages. For closing tab, the user can use ctrl-F4 instead.

在 2011年3月30日 上午10:49，Peter Kasting <pkas...@google.com>写道：

On Wed, Mar 30, 2011 at 10:45 AM, Caleb Eggensperger <cale...@gmail.com> wrote:

I thought the original reason was hung renderers, not malicious pages.

Hung renderers was a primary problem, but malicious apps were also discussed, and even if they hadn't been they'd be in scope here anyway.

But a malicious app can always hook window.onbeforeunload to prevent its window from being closed. Intercepting ctrl-w won't help for such case.

 

Also, the user could always use the close button.

UI can never rely on the mouse as the sole way of doing something.

PK

--

[Charlie Reis]

On Wed, Mar 30, 2011 at 11:27 AM, James Su <su...@chromium.org> wrote:

I'd actually prefer to remove ctrl-[a-z] from reserved accelerator list and give them to web pages. For closing tab, the user can use ctrl-F4 instead.

That's not a good option on all platforms, and it's less well known.

 

在 2011年3月30日 上午10:49，Peter Kasting <pkas...@google.com>写道：

On Wed, Mar 30, 2011 at 10:45 AM, Caleb Eggensperger <cale...@gmail.com> wrote:

I thought the original reason was hung renderers, not malicious pages.

Hung renderers was a primary problem, but malicious apps were also discussed, and even if they hadn't been they'd be in scope here anyway.

But a malicious app can always hook window.onbeforeunload to prevent its window from being closed. Intercepting ctrl-w won't help for such case.

 

Users can always dismiss beforeunload handlers with "Leave this Page."  The worst the page can do is go into an infinite loop (in which case we'll time out and navigate away anyway) or show more dialog boxes (which can be suppressed with a checkbox by the user).

Peter has a valid point here about wanting to keep Ctrl+W, etc, for the browser.  However, I think the idea of letting installed web apps or extensions request permission to intercept it could be reasonable, if we thought it through.

Charlie

[Wez]

If we identify (possibly even standardise) a small set of shortcuts sufficient to provide easy get-out from a broken or malicious app, would that address both the security/stability and web-app shortcut requirements?

If so then an API could be provided to disable all non-essential shortcuts, leaving only a small set un-hookable by the app or plugin.  That set could conceivably be further reduced while full-screen, since that is normally a state in which the user is less likely to want to use most shortcuts except exit-fullscreen or close-tab.

If a web app does choose to disable some/all shortcuts, it might help to reflect it in the UI. The Application Shortcut feature of Chrome brings up a web app in a more application-like frame, predisposing the user to expect it to behave like a native application more than like a web page.  Without the visual cue, the user's understanding of the shortcut keys will need to adjust between tabs even in a single browser - if their text editor app uses Ctrl+W for saving the file, for example, and they then try that in any other tab they will end up sorely disappointed.

Cheers,

Wez

[Todd Vierling]

On Wed, Mar 30, 2011 at 2:39 PM, Wez <w...@chromium.org> wrote:
> If we identify (possibly even standardise) a small set of shortcuts
> sufficient to provide easy get-out from a broken or malicious app, would
> that address both the security/stability and web-app shortcut requirements?
> If so then an API could be provided to disable all non-essential shortcuts,
> leaving only a small set un-hookable by the app or plugin.

Some platforms (e.g., Chrome OS) don't have Fn keys on some hardware,
so the only available shortcut keys are the standard modifiers (Ctrl,
Alt, Shift). Regardless, for an example app that provides VNC-like
functionality (<cough>Chromoting<ahem>), _all_ such keys -- including
Fn and modifiers for it -- are valid for the application, and there's
nothing left to leave "un-hookable".

> If a web app does choose to disable some/all shortcuts, it might help to
> reflect it in the UI.

Permissions infobar, perhaps, as suggested.

> The Application Shortcut feature of Chrome brings up a
> web app in a more application-like frame, predisposing the user to expect it
> to behave like a native application more than like a web page.

This doesn't exist in Chrome OS, as the window manager is very different.

[Evan Martin]

I think this is reasonable.

It also fits in nicely with the idea of apps as packages of
permissions: a fancy webapp (like the 280 North stuff) would
definitely want the "intercept all keys" permission, as they use Ctl-W
to close "windows" within the page.

The way to move forward on this is:
1) write a more concrete proposal, in the form of what the API would
look like (dev.chromium.org has similar proposals); run this by
chromium-dev to see if there are any objections
2) implement this for Chrome under some experimental prefix
3) see if you can get any other browser vendors interested

[Wez]

On 30 March 2011 23:18, Todd Vierling <t...@duh.org> wrote:

On Wed, Mar 30, 2011 at 2:39 PM, Wez <w...@chromium.org> wrote:
> If we identify (possibly even standardise) a small set of shortcuts
> sufficient to provide easy get-out from a broken or malicious app, would
> that address both the security/stability and web-app shortcut requirements?
> If so then an API could be provided to disable all non-essential shortcuts,
> leaving only a small set un-hookable by the app or plugin.

Some platforms (e.g., Chrome OS) don't have Fn keys on some hardware,
so the only available shortcut keys are the standard modifiers (Ctrl,
Alt, Shift). Regardless, for an example app that provides VNC-like
functionality (<cough>Chromoting<ahem>), _all_ such keys -- including
Fn and modifiers for it -- are valid for the application, and there's
nothing left to leave "un-hookable".

VNC usually priovides an "F8 menu".  Whether the viewer is windowed or full-screen, that key is the one-and-only magic escape "hot key" that will get you to a control menu for a viewer, rather than being passed to the server.  It can be configured, and if the user really wants then it can be disabled - but that's a user configuration decision, not something the remote end can (request to) change.

> If a web app does choose to disable some/all shortcuts, it might help to
> reflect it in the UI.

Permissions infobar, perhaps, as suggested.

> The Application Shortcut feature of Chrome brings up a
> web app in a more application-like frame, predisposing the user to expect it
> to behave like a native application more than like a web page.

This doesn't exist in Chrome OS, as the window manager is very different.

True.  It could support something similar, though, in principle.

[chrelad]

Allowing access to special keys via an API seems to me to be the best
approach. Using a common API, you can conceivably allow the user to
control which keys are accessible by which sites; just as you can
specify which sites can display notifications. With an API, you also
have the ability to show a notification bar at the top of the site
letting the user know that the site is requesting access to special
keys and allow the user to "allow" or "deny" as they see fit. As far
as I can tell, it would mitigate the risk of malicious sites grabbing
special keys in order to prevent users from navigating away, etc. +1.

On Mar 30, 12:36 pm, Peter Kasting <pkast...@chromium.org> wrote:

[Wez]

Has any progress been made on developing a prototype API for this?

Wez

[Peter Kasting]

On Fri, May 27, 2011 at 6:16 PM, Wez <w...@chromium.org> wrote:

Has any progress been made on developing a prototype API for this?

I think this is going to depend on someone passionate taking this issue and running with it.  If this is something that you're especially interested in I encourage you to develop this into a more formal proposal; it seems like there's general agreement that it's at least worth going that far.

PK

[Wez]

Passionate is perhaps putting it a little strongly; interested might be more the mark.  I'll take a look.

Did anyone enter a bug for this?  I don't see one, searching for "special keys".

Cheers,

Wez

[Peter Kasting]

On Fri, May 27, 2011 at 6:29 PM, Wez <w...@chromium.org> wrote:

Passionate is perhaps putting it a little strongly; interested might be more the mark.  I'll take a look.

Did anyone enter a bug for this?  I don't see one, searching for "special keys".

I don't think there is one.  http://code.google.com/p/chromium/issues/detail?id=25756 might be the closest bug, I dunno.  Just file a new one if need be.

PK 

[Todd Vierling]

On Fri, May 27, 2011 at 9:34 PM, Peter Kasting <pkas...@chromium.org> wrote:
> I don't think there is one.
>  http://code.google.com/p/chromium/issues/detail?id=25756 might be the
> closest bug, I dunno.  Just file a new one if need be.

http://crbug.com/32787 is the real issue, which you marked as WontFix
rather than leaving it open in search of an appropriate/useful answer.
Since that was marked as WontFix, at least one other related issue has
already been opened in its wake, http://crbug.com/84288 (which deals
with Chromoting, an issue I specifically pointed out in the comments
for 5496, which naustin subsequently copied to the comments of 32787).

I would recommend reopening 32787 so that it isn't lost forever in the
mail list noise, and it's likely that 84288 should be merged into it.

[Peter Kasting]

On Fri, May 27, 2011 at 7:22 PM, Todd Vierling <t...@duh.org> wrote:

I would recommend reopening 32787 so that it isn't lost forever in the

mail list noise

That bug is about firing the events all the time.  Since we're not going to do that, I'm not going to reopen and then morph the bug into something else.

I filed http://crbug.com/84332 to cover this.

PK

[Wez]

Peter, Todd,

Thanks for bringing me up to date on this.  I'll take a look and see what we can do.

Wez