Issue 33056 in chromium: Ctrl keys: Ctrl-N, Ctrl-T and Ctrl-W no longer available to client side JavaScript in Chrome4 (available in FF3.x, IE7/8 and Chrome3).
chro...@googlecode.com
Owner: ----
Labels: Type-Bug Pri-2 Area-Undefined
New issue 33056 by nsbayl...@tiscali.co.uk: Ctrl keys: Ctrl-N, Ctrl-T and
Ctrl-W no longer available to client side JavaScript in Chrome4 (available
in FF3.x, IE7/8 and Chrome3).
http://code.google.com/p/chromium/issues/detail?id=33056
Chrome Version : 4.0.249.64(35722)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 4: Not tested
Firefox 3.x: OK
IE 7: OK
IE 8: OK
What steps will reproduce the problem?
1. Load the attached simple web page in each browser.
2. Position the cursor in the input field and press Ctrl-N
3. If using Chrome, open the web page afresh and press Ctrl-T
4. If using Chrome, open the web page afresh and press Ctrl-W
5. As above but using Ctrl-Shift-N, Ctrl-Shift-T and Ctrl-Shift-W.
What is the expected result?
The text "Ctrl-N", "Ctrl-T" or "Ctrl-W" (as appropriate) should appear in
the blue div and the default action of the Control key should be prevented.
(Similarly with Ctrl-Shift-N, Ctrl-Shift-T and Ctrl-Shift-W.)
What happens instead?
In Chrome4 the browser executes the default action (i.e. open new window,
open new tab and close tab/window) and does not execute the JavaScript
intercept (at all).
In IE7, IE8, FF3, FF3.5 and Chrome3 the intercept works fine.
Please provide any additional information below. Attach a screenshot if
possible.
In Chrome4, certain control key combinations have been reserved for browser
usage only and can no longer be intercepted by the client side JavaScript
in the web page.
These restrictions did not exist in Chrome3 and are inconsistent with both
Firefox3/3.5 and IE7/8 (on Windows).
They are unnecessary in my view, and have prevented me from implementing
certain user friendly keyboard interactions consistently across the major
browsers.
I am developing a brand new browser based business application and had
already implemented Ctrl-N as a familiar shortcut for "New Record" which
now no longer works in Chrome4. It works OK in FF and IE, and I can still
use Ctrl-S for "save" and Ctrl-P for "print" across the board. I'd also
like to be able to use Ctrl-T and Ctrl-W amongst other key combinations.
The current situation in Chrome4 appears to be due changes made under issue
5496 (which also includes issue 5659). The two main reasons given in these
issues are slightly slower response when using Ctrl-T instead of button
click to manipulate browser tabs (5659) , and to stop malicious code
preventing a user from closing a browser tab (or the browser itself) via
the keyboard (e.g. by using Ctrl-W).
I feel that not all the changes made are justifiable, as they restrict the
web page author from using these specific keyboard usability features
consistently across the major browsers.
I really can't see any good reason for preventing intercept of Ctrl-N or
Ctrl-T for example. It's extremely unlikely a malicious page would seek to
block these, and even if it did, it shouldn’t cause any real problem as far
as I can see. I'd have hoped these performance of these could be improved
without having to reserve these keys, but if not, it's a price worth paying
for making the web page content itself more usable. I also can't see why
Ctrl-W needs to be reserved, in Windows at least, since Alt+F4 is always
available to close the browser.
I therefore would request that the following key combinations should be
reinstated as ones that can validly be intercepted (and default actions
prevented) by client side JavaScript.
Ctrl-N, Ctrl-Shift-N,
Ctrl-T and Ctrl-Shift-T.
Ctrl-W, Ctrl-Shift-W,
It would also be useful to have access to the following combinations as
well, although these aren't handled consistently between FF and IE.
Ctrl-Tab and Ctrl-Shift-Tab.
Attachments:
test_keys1.htm 1.4 KB
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
chro...@googlecode.com
Comment #1 on issue 33056 by simon.bohlin: Ctrl keys: Ctrl-N, Ctrl-T and
in FF3.x, IE7/8 and Chrome3).
http://code.google.com/p/chromium/issues/detail?id=33056
Also related: Issue 27559
chro...@googlecode.com
Comment #7 on issue 33056 by ewering: Ctrl keys: Ctrl-N, Ctrl-T and Ctrl-W
FF3.x, IE7/8 and Chrome3).
http://code.google.com/p/chromium/issues/detail?id=33056
Another note: What clearly *is* a bug that needs fixing is that Ctrl-W
doesn't even fire the "unbeforeunload" event, so my application can't even
ask the user if he/she wants to save the currently open file(s). That makes
this problem even more cynical... ;)
chro...@googlecode.com
Comment #8 on issue 33056 by anders.sandberg.nordbo: Ctrl keys: Ctrl-N,
(available in FF3.x, IE7/8 and Chrome3).
http://code.google.com/p/chromium/issues/detail?id=33056
You're sure that typo isn't copied from your code? "unbeforeunload" should
be "onbeforeunload" right?
chro...@googlecode.com
Comment #13 on issue 33056 by drisac...@gmail.com: Ctrl keys: Ctrl-N,
(available in FF3.x, IE7/8 and Chrome3).
http://code.google.com/p/chromium/issues/detail?id=33056
Also note that in addition to Ctrl-NTW, I second the OP's inclusion of
Ctrl-Tab, and Shift-Ctrl-Tab.
chro...@googlecode.com
Comment #16 on issue 33056 by olga.tsi...@gmail.com: Ctrl keys: Ctrl-N,
(available in FF3.x, IE7/8 and Chrome3).
http://code.google.com/p/chromium/issues/detail?id=33056
chro...@googlecode.com
Comment #19 on issue 33056 by Aqu...@gmail.com: Ctrl keys: Ctrl-N, Ctrl-T
(available in FF3.x, IE7/8 and Chrome3).
http://code.google.com/p/chromium/issues/detail?id=33056
Offense intended, but you've really pissed me off as a developer. Thanks,
Chrome.
This severely needs to be modified, Chrome has no right to override a web
app.
You can't expect us to build desktop class web applications if you
purposely go skrewing around with the tools we need to create them.
chro...@googlecode.com
Comment #22 on issue 33056 by tszynal...@antimoon.com: Ctrl keys: Ctrl-N,
(available in FF3.x, IE7/8 and Chrome3).
http://code.google.com/p/chromium/issues/detail?id=33056
Of course you want Ctrl+N to open a new window. Except when you're using
vim in your browser, then you want it to find the next match
(autocompletion) because that's what you're used to. Or when you're using
spanish.typeit.org - then you want it to type ñ because there is no other
logical shortcut for it.
Look, everyone posting here is aware that overriding Ctrl+NTW has certain
undesirable usability consequences. However, there are some legitimate uses
where the benefits outweigh the disadvantages.
Finally, allowing webapps to handle Ctrl+NTW will have no negative effect
on your browsing experience. Page designers will have little reason to
override the default browser behavior, unless absolutely necessary. In
fact, you might never come across a website that does. (Malicious use is
unlikely for reasons I explained in one of my earlier posts here.)
Respectfully,
Tomasz P. Szynalski
chro...@googlecode.com
Comment #23 on issue 33056 by n...@smartaustin.com: Ctrl keys: Ctrl-N,
(available in FF3.x, IE7/8 and Chrome3).
http://code.google.com/p/chromium/issues/detail?id=33056
As I mentioned earlier, adding a Javascript API extension which app
developers are required to call before they can capture all keys would
solve all of the unresponsive script problems.
If we're really worried about malicious use, then we can make a Allow/Deny
prompt like the one which is used for location data.
Thanks!
chro...@googlecode.com
Comment #24 on issue 33056 by sam.has...@gmail.com: Ctrl keys: Ctrl-N,
(available in FF3.x, IE7/8 and Chrome3).
http://code.google.com/p/chromium/issues/detail?id=33056
@Tomasz:
"Of course you want Ctrl+N to open a new window. Except when you're using
vim in your browser"
"there are some legitimate uses where the benefits outweigh the
disadvantages."
The problem is that if it's allowed then it won't only be used on a few
sites where it might possibly make sense but also in places where it
doesn't make sense, or where users aren't expecting it to be used. By
disallowing it users are guaranteed to have consistent keyboard shortcuts
that they can rely on. It's only going to frustrate people when they try a
site out and then find it's overriden the shortcuts.
chro...@googlecode.com
Comment #25 on issue 33056 by sam.has...@gmail.com: Ctrl keys: Ctrl-N,
(available in FF3.x, IE7/8 and Chrome3).
http://code.google.com/p/chromium/issues/detail?id=33056
@Tomasz,
"Ctrl+W is rarely used (Alt+F4 is much more popular)"
I use Ctrl+W all the time to close the current tab. I'm sure a large
proportion of users do too. Alt+F4 would close the entire window so I'm not
sure why you're comparing them.
chro...@googlecode.com
Comment #26 on issue 33056 by hussain2...@gmail.com: Ctrl keys: Ctrl-N,
(available in FF3.x, IE7/8 and Chrome3).
http://code.google.com/p/chromium/issues/detail?id=33056
F**k Crome! not good for web developers
chro...@googlecode.com
Comment #27 on issue 33056 by jordonwii: Ctrl keys: Ctrl-N, Ctrl-T and
in FF3.x, IE7/8 and Chrome3).
http://code.google.com/p/chromium/issues/detail?id=33056
@sam.hasler: But if users would have to give permission to sites via
prompt, then there will always be the expectation by the user that these
shortcuts will be used by the website. There would never be an instance
where a site could map these shortcuts without confirmation by the user.
To be completely honest, I'm fairly certain the number of people who use
Ctrl+W is extremely small. I use it every so often, but ordinary users,
the type of user who the devs are concerned with, likely very rarely use it.
chro...@googlecode.com
Comment #28 on issue 33056 by tszynal...@antimoon.com: Ctrl keys: Ctrl-N,
(available in FF3.x, IE7/8 and Chrome3).
http://code.google.com/p/chromium/issues/detail?id=33056
@Sam:
"The problem is that if it's allowed then it won't only be used on a few
sites where it might possibly make sense but also in places where it
doesn't make sense, or where users aren't expecting it to be used."
1. Maybe I haven't thought about it long enough, but I don't think it's
something that would be commonly abused. Who would want to override
Ctrl+WNT without a good reason? (So far I haven't seen any examples,
although it is possible in IE & Firefox.)
2. The fact that a feature can theoretically be used in a frustrating way
is not a sufficient reason to disable it. For example, I am frustrated by
sites that show you an annoying "Are you sure you want to leave the site?"
popup when you try to close them. But I don't believe that this feature
should be removed from browsers, because it can be useful in many cases.
Similarly, I could rewrite your argument to argue that websites should not
be able to set the color of hyperlinks: "If we allow them to do that, they
will use it not only in ways that make sense, but also in ways that don't
make sense (e.g. making links hard to distinguish from regular text). By
disallowing it users are guaranteed to have a consistent hyperlink look
that they can rely on."
3. In my opinion, browsers should try to offer as many features as
possible, unless it is demonstrated that for the average user, a particular
feature causes more harm than good (example: javascript pop-ups). In the
case at hand, it has not been demonstrated. There's just general "but what
if websites use it wrong?" talk.
chro...@googlecode.com
Comment #31 on issue 33056 by sam.has...@gmail.com: Ctrl keys: Ctrl-N,
(available in FF3.x, IE7/8 and Chrome3).
http://code.google.com/p/chromium/issues/detail?id=33056
@Tomasz,
> Similarly, I could rewrite your argument to argue that websites should
> not be able to set the color of hyperlinks: "If we allow them to do that,
> they will use it not only in ways that make sense, but also in ways that
> don't make sense (e.g. making links hard to distinguish from regular
> text). By disallowing it users are guaranteed to have a consistent
> hyperlink look that they can rely on."
The colour of hyperlinks only affects how that website looks. Overriding
shortcuts for browser behaviour can affect the user when they aren't paying
attention to which tab they are on. e.g.:
a) with focus on the rightmost tab, trying to close the last 3 tabs, with
the middle of those overriding CTRL+W.
The annoying "Are you sure you want to leave the site?" popup at least
provides some feedback as to that is going on. If a site overrides CTRL+W
because it doesn't want to make it easy for users to leave there would be
no indication that the site had done it and the user may attribute blame to
chrome.
b) Switching to the browser with ALT+TAB and then trying to open a new
window or tab with CTRL+T/N
c) Moving through the tabs with CTRL+TAB
"browsers should try to offer as many features as possible" that is
completely opposite to how chrome was designed. They have tried to remove
as many settings and choices from the user as possible by picking sensible
defaults or designing it in such a way that there is no need for the user
to make a choice.
chro...@googlecode.com
Comment #32 on issue 33056 by maik.ku...@gmail.com: Ctrl keys: Ctrl-N,
(available in FF3.x, IE7/8 and Chrome3).
http://code.google.com/p/chromium/issues/detail?id=33056
Maybe the browser window itself shouldn't allow resetting those shortcuts
but what about apps? If you have only the app-window shortcuts like
Ctrl+Tab or Ctrl+W are (at least in my opinion) not considered critical so
allowing the app to override would be a pretty nice feature..
chro...@googlecode.com
Comment #37 on issue 33056 by tszynal...@antimoon.com: Ctrl keys: Ctrl-N,
(available in FF3.x, IE7/8 and Chrome3).
http://code.google.com/p/chromium/issues/detail?id=33056
@Nick:
A user dialog would certainly solve the problem, but isn't there a simpler
solution? What happens if you put some expensive JS in an onbeforeunload
handler, and then try to close the tab? How does Chrome handle it?
One idea is that the browser could give the webpage a certain small amount
of time to handle a keystroke and, if there's no reaction, close the tab.
chro...@googlecode.com
Comment #39 on issue 33056 by albert.d...@gmail.com: Ctrl keys: Ctrl-N,
(available in FF3.x, IE7/8 and Chrome3).
http://code.google.com/p/chromium/issues/detail?id=33056
I'm a heavy keyboard user and almost exclusively use ctrl+w to close tabs
in practically all applications I use (most notably browser & eclipse). I'm
building a web application that initially targeted firefox/chrome, but it
also uses tabs on the page itself. I want to support what users (including
myself) are used to, which is ctrl+w to close a tab in the web application.
That said, I refuse to remap the default combination to something no one is
used to.
Removing the ability to intercept it because of malicious uses is absurd as
in all my years of firefox browsing only one thing has bugged me with such
an issue: flash; not some javascript application. Luckily we have this
magical device called a "mouse" that can sidestep such malicious brilliance.
Additionally I would like to emphasize that as mentioned above, only
advanced users tend to use keyboard shortcuts which means malicious sites
have little to gain by blocking these. Unlucky for me perhaps that the
advanced users are my target audience for this web application. Well
there's always firefox ey?
chro...@googlecode.com
Comment #40 on issue 33056 by taker...@chartasoftware.com: Ctrl keys:
Chrome4 (available in FF3.x, IE7/8 and Chrome3).
http://code.google.com/p/chromium/issues/detail?id=33056
Could somebody confirm that this issue also applies to CTRL+mousewheel?
Chrome seems to execute default page zooming instead of specific JS code no
matter what I try.
Thanks