diff options
| author | avi@chromium.org <avi@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-08-11 14:52:57 +0000 |
|---|---|---|
| committer | avi@chromium.org <avi@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-08-11 14:52:57 +0000 |
| commit | ce4575185befd1ee165f3e01d52fb3fea4b72675 (patch) | |
| tree | 83037f8a893492c618f7f874fb95d7939baaf72c /webkit | |
| parent | 7cd83d1caff7fa1090d9fc8eadb7474cb3b811f2 (diff) | |
| download | chromium_src-ce4575185befd1ee165f3e01d52fb3fea4b72675.zip chromium_src-ce4575185befd1ee165f3e01d52fb3fea4b72675.tar.gz chromium_src-ce4575185befd1ee165f3e01d52fb3fea4b72675.tar.bz2 | |
Mac: Make the password-field capslock indicator work again.
Since we DCHECK() that the event should be some sort of key-up or down
(now raw, which was the problem), there's no particular reason to check
for the type, is there?
(Fix required pointed out by hbono.)
Patch by viettrungluu.
BUG=http://crbug.com/18807
TEST=Go to web page with password field (e.g., gmail login) and select it; cycle
capslock.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23024 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'webkit')
| -rw-r--r-- | webkit/glue/webview_impl.cc | 5 |
1 files changed, 1 insertions, 4 deletions
diff --git a/webkit/glue/webview_impl.cc b/webkit/glue/webview_impl.cc index 6660474..c1c1f1e 100644 --- a/webkit/glue/webview_impl.cc +++ b/webkit/glue/webview_impl.cc @@ -607,11 +607,8 @@ bool WebViewImpl::KeyEvent(const WebKeyboardEvent& event) { // It's not clear if we should continue after detecting a capslock keypress. // I'll err on the side of continuing, which is the pre-existing behaviour. - if (event.windowsKeyCode == base::VKEY_CAPITAL && - (event.type == WebInputEvent::KeyUp || - event.type == WebInputEvent::KeyDown)) { + if (event.windowsKeyCode == base::VKEY_CAPITAL) handler->capsLockStateMayHaveChanged(); - } MakePlatformKeyboardEvent evt(event); |