Ctrl-W support and Chrome as an application platform.

[Nick Austin]

Hey.

I'm trying to switch to Chrome OS as my exclusive laptop computing
device, and I'm happy to say I'm 95% there.

The last major remaining issue was remote terminal access.

I've found a tool called Shell in a Box which works wonderfully and
basically completes the Chrome OS solution for me.
With it, I can edit code, and run the world directly from the laptop.

There is one minor chink in this otherwise awesome solution.
Ctrl-W support is broken.

Without Ctrl-W, Shell in a box and related solutions are basically
worthless on Chrome OS.

After some digging, I found this:
http://code.google.com/p/chromium/issues/detail?id=5496 (Figure out
how to deal with sluggish renderers blocking accelerators)

The gist of this bug is that some websites can slow Chrome down in a
way that causes window management keys to respond more slowly.
The solution we came up with was to shunt these keys directly to the
chrome window management framework.

I'd argue that the cost of this change was too high.

We need a way to allow apps like Shell in a box to function fully on
Chrome OS, and Ctrl-W is vital to Emacs, Bash, vim, etc, etc.
I've though of a number of solutions for this problem.

1) Revert the change in 5496, and improve the renders so that they do
not block. This feels like the most elegant solution.
2) Analise the JavaScript on a given page and only send Ctrl-W to the
render if needed.
3) (variant on 2) Add a JavaScript function call which allows the
program to request access to keys like Ctrl-W, etc. (If 2 is not
feasible.)
4) We can further extend the concept in 3 by showing an allow or deny
access dialog à la the geo location dialog.
5) We can make the preference for these keys a configuration option.
(My second least favored option)

Thanks!

[James Su]

Maybe we should support Emacs editing keys on Chrome OS.

btw, I really like Mac's command key, which avoids such kind of conflict effectively.

Regards

James Su

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

[Nick Austin]

On Tue, Mar 1, 2011 at 5:41 PM, James Su <su...@chromium.org> wrote:

Maybe we should support Emacs editing keys on Chrome OS.

That would fix my problem nicely!

Perhaps Ctrl-W is more important on Chrome OS, since we don't really need a full app platform on the desktop anyway.

That's what Windows/Mac/Linux is for. :-)

Thanks! 

--
Nick Austin                     Google Ads SRE
Work:  +1 (425)739-5841  Cell: +1 (415) 843-1337

[Nick Austin]

On Tue, Mar 1, 2011 at 6:12 PM, Nick Austin <nau...@google.com> wrote:

On Tue, Mar 1, 2011 at 5:41 PM, James Su <su...@chromium.org> wrote:

Maybe we should support Emacs editing keys on Chrome OS.

That would fix my problem nicely!

I think this also gets to the heart of the issue.

Pressing Ctrl-W and having the current tab close if that's what you want is nice.

Pressing Ctrl-W and having the tab close if that's not what you wanted is a disaster.

Like I mentioned earlier, this behavior in Chrome prevents it from being used in a whole class of applications.

So while the user base for these apps may be smaller today, the impact on them is huge.

It prevents many engineers from being able to using Chrome OS as primary laptops.

Thoughts?

[Caleb Eggensperger]

Here's a somewhat related issue:

http://code.google.com/p/chromium/issues/detail?id=25756#c15

Changing this to take Ctrl+W off the list of keyboard shortcuts that
can be overridden would open them up to plugin-eating. There's a huge
amount of debate in that thread about what keyboard shortcuts should
be overridable. It seems to be a somewhat contentious topic (89
comments, many rants).

My .02: I use Shell In A Box regularly too, and I prefer Ctrl+W
closing the tab because it's more in line with my expectations and
use. (but I use vim, so I can't speak to how annoying this might be in
emacs). I don't feel strongly about this though.

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

--
Caleb Eggensperger
www.calebegg.com

[Nick Austin]

On Wed, Mar 2, 2011 at 1:32 PM, Caleb Eggensperger <cale...@gmail.com> wrote:

Here's a somewhat related issue:

http://code.google.com/p/chromium/issues/detail?id=25756#c15

Changing this to take Ctrl+W off the list of keyboard shortcuts that
can be overridden would open them up to plugin-eating. There's a huge
amount of debate in that thread about what keyboard shortcuts should
be overridable. It seems to be a somewhat contentious topic (89
comments, many rants).

This would seem to be an argument for making this an option.

My .02: I use Shell In A Box regularly too, and I prefer Ctrl+W
closing the tab because it's more in line with my expectations and
use. (but I use vim, so I can't speak to how annoying this might be in
emacs). I don't feel strongly about this though.

I'm suppressed that a Shell in a box user is not crippled by the loss of Ctrl-W. 

Do you just remap it everywhere?

I'm a vim user as well. Ctrl-W is the key to manage view ports in vim.

It's also the key to delete a word in all readline enabled apps in the shell environment, so

I use it often in that context.

The fact that another Shell in a box user indicates that Ctrl-W closing the tab does not bother

them would seem to push this toward being an option. I could see it like this:

Window manage key behavior: <Browser only>, <Webpage then browser>

What do you think of that?

Thanks!

[Caleb Eggensperger]

I think it would be nice if a solution could be found that didn't
require addition of a somewhat niche and esoteric setting. Perhaps
apps and extensions would be given the opportunity to override the
more core system keyboard shortcuts. Then you could create an app
shortcut for your siab to let it override Ctrl+W (that would probably
be all it would take, as I'm sure it's already trying to). Or
frustrated users could install a "give web content access to more
shortcuts" extension.

I've never really gotten into Vim's windows feature. I've tried it in
the past and found the ^W hjkl shortcuts more awkward than just
cmd+`ing to different (Mac)Vim instances. Also, most of what I'm doing
from siab is minor stuff that doesn't require more than one file
anyway (school/personal projects, restarting my Minecraft server,
etc). I've never used ^W in bash either, and didn't know what it did
until now (and dammit, now I'm going to get used to it; you've
infected me. :-P)

[Nick Austin]

On Wed, Mar 2, 2011 at 2:11 PM, Caleb Eggensperger <cale...@gmail.com> wrote:

I think it would be nice if a solution could be found that didn't
require addition of a somewhat niche and esoteric setting.

I tend to agree. I like fewer settings in general.

In this case, it seems there is no agreement possible.

There are many people who like the keys going directly to the browser (including core Chrome devs), so

obviously we can't just have the original change reverted.

But then we have a small number of people on like me who this change completely craters.

I'd much rather have a browser I can use for everything, with the occasional tab I need to click the X on to close.

Perhaps apps and extensions would be given the opportunity to override the
more core system keyboard shortcuts. Then you could create an app
shortcut for your siab to let it override Ctrl+W (that would probably
be all it would take, as I'm sure it's already trying to).

I like this option the most.

 

Or frustrated users could install a "give web content access to more
shortcuts" extension.

I had not though of that! This is a great idea!

It keeps the options simple, and allows web site devs to point users at an extension if

they want to make the browser development environment richer.

 

I've never really gotten into Vim's windows feature. I've tried it in
the past and found the ^W hjkl shortcuts more awkward than just
cmd+`ing to different (Mac)Vim instances.

Fair enough. This problem is most noticeable for me on Chrome OS

where I don't have a good terminal without Shell in a box.

When I'm on a computer with local apps, I just use the terminal app.

Also, most of what I'm doing from siab is minor stuff that doesn't require more than one file
anyway (school/personal projects, restarting my Minecraft server,
etc).

I use multi-viewports mostly for coding.

I can view the function definition in a small window

while editing code which calls the function below. And

other related activities.

This is even more important in Chrome OS where you can not have two terminals

visible at the same time.

I've never used ^W in bash either, and didn't know what it did
until now (and dammit, now I'm going to get used to it; you've
infected me. :-P)

Nice!

Also check out Ctrl-R to reverse search though your history.

Here's to more productive shell use. :-)

Thanks!

[Nick Austin]

On Wed, Mar 2, 2011 at 2:32 PM, Nick Austin <nau...@google.com> wrote:

I tend to agree. I like fewer settings in general.

In this case, it seems there is no agreement possible.

It seems there are fewer people with opinions on this then I anticipated.

What is the opinion on having a config option vs using JavaScript analysis?

[Ben]

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

I think there should be a key combination (say, Alt+`) which toggles
between the browser's shortcuts and page+extension shortcuts. Extensions
should have priority over pages, but only on the pages for which the
extensions have requested permission, unless it uses a special extension
api to request the shortcut (in which case, the extension shares the
keyboard with the browser instead of the webpage.

So, it'd look something like this:

Key-toggled == True:
send events to extension then webpage
key-toggled == False:
send events to extension or browser
(shortcuts shouldn't overlap with each other in this world)
if neither extension nor browser uses the event:
send to the webpage (optional/arguable whether this is what we want)

[lbdyer]

The controversy always exists around the incomplete solutions. The
only __complete__ solution in this case, due to the existence and (!)
the potential of the Chromium OS is to implement a __full__ keyboard
map (+ predefined schemes) in the options, passing the control over to
the end-user.

You'll all agree, I hope, that the accelerators are of primary, even
exclusive, use to the power users, who can always, and quickly, find
their way around the obstacles arising from sites or plugins
"stealing" some or all of the accelerators, or not being responsive
for that matter. The accelerators are exactly this - accelerators,
they're to enhance productivity, so, in a future that we all look
forward to, and you work hard for (thanks!) - i.e. the OS is the
Browser, the Browser is the OS - you don't want to limit the
innovation by "stealing" the ability of the web applications to
provide first class productivity to their users. Thinking about the
potential of the Chromium (OS), do we want to use the old Web 1
(magazine-style) application model, which, among other things, is
breaking our flow of thought? Certainly, the ultimate result of your
hard work will be the web applications growing expenentially in
complexity and (already true) making use of ALL of the accelerators.
An application can restrict some of the keys for its own use - an
Operating System cannot!

I'm sure you will agree, again, that the biggest evil for every web
developer, trying to follow the public standards (and unfortunately
the de-facto standards) is to have something possible in all browsers
but one, which is the case in this particular problem (not just the
Ctrl-W but many of the important accelerators). We're the ones that
leverage your efforts, do not limit our ability to innovate - we DO
need a full app platform on the desktop for many reasons, the most
important one being that we're not restricted to a single device
anymore, while all of them (the devices) share only the access to the
wide web.

-- Best

[Tom]

This to me looks like this would be optimal:

Distinguish between Chrome's App mode and its tabbed-browser mode. In
App mode, i.e. when calling chrome with --app, send ALL keys to the
renderer, except perhaps Shift+Esc (since there's no way for a normal
user to distinguish between app processes in the system process list.)
App developers can capture these keys when available (in app mode) and
degrade when they aren't (in tab mode or in other browsers).

The above would work on Windows and other stand-alone versions of
Chrome.

I don't use Chrome OS but it looks as though Chrome tabs are the
lowest-level app-switching mechanism there. If so, I think that's a
huge design mistake - because it effectively substitutes a new set of
shortcuts for the well-established low-level commands like Alt-Tab and
Alt-F4 or their equivalents. So app developers can't use any of either
set.

(I can't understand why Chrome has chosen to take two divergent
approaches - apps as tabs, subordinate to the browser, and apps as OS-
level processes, browser shrunk to a stub. The latter is the one I
want to see developed, and I'm worried that the app-in-browser-tab
paradigm is threatening that.)

Thomas

[Jason Dunn]

I am another person who needs to be able to hit Ctrl-W to work (in the shell and vim).

[david manea]

could always press Ctrl-Shift-T bro

On Tuesday, March 1, 2011 7:14:16 PM UTC-6, Nick Austin wrote:

[Trent Apted]

Packaged apps can help you here. E.g. I just tried out 'FireSSH' on my Chromebook and Ctrl+W worked correctly in the terminal -- link: https://chrome.google.com/webstore/detail/firessh/mcognlamjmofcihollilalojnckfiajm

--

[Evans Turner]

For me, I'm more comfortable using Ctrl+F4 to close tabs anyway. I know this works in Chrome for Windows. Not sure about Chrome OS.

-Evans