diff options
author | suzhe@chromium.org <suzhe@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-10-23 01:15:33 +0000 |
---|---|---|
committer | suzhe@chromium.org <suzhe@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-10-23 01:15:33 +0000 |
commit | ed8bf13bccd28196fa2e1ddd30dc98a100167919 (patch) | |
tree | e721a87554d87716db83adcbdcc6c1cdeb109f60 /chrome/browser/renderer_host/render_widget_host.h | |
parent | 9febdb951b2a75ae69c2b2153c94ee5be86bb3ed (diff) | |
download | chromium_src-ed8bf13bccd28196fa2e1ddd30dc98a100167919.zip chromium_src-ed8bf13bccd28196fa2e1ddd30dc98a100167919.tar.gz chromium_src-ed8bf13bccd28196fa2e1ddd30dc98a100167919.tar.bz2 |
Fix conflicts between accelerator keys and HTML DOM accesskeys.
This CL fixes conflicts between accelerator keys and HTML DOM accesskeys by suppressing Char events if corresponding RawKeyDown event was handled by the browser after returning from the renderer unhandled.
This CL not only fixes this conflict issue, but also makes the behavior of handling accelerator keys similar than IE, which also suppresses a key press event if the key down event was handled as an accelerator key.
BUG=21624 accesskey attributes conflict with browser shortcuts (like tab-switching)
TEST=Open http://djmitche.github.com/buildbot/docs/0.7.11/ in one of opened multiple tabs, switch to another tab by pressing an alt-# key binding, then switch back to the original page to see if it's just as you left it before switching tabs.
Review URL: http://codereview.chromium.org/235039
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29857 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/browser/renderer_host/render_widget_host.h')
-rw-r--r-- | chrome/browser/renderer_host/render_widget_host.h | 46 |
1 files changed, 43 insertions, 3 deletions
diff --git a/chrome/browser/renderer_host/render_widget_host.h b/chrome/browser/renderer_host/render_widget_host.h index 01fce6c..39b3e07 100644 --- a/chrome/browser/renderer_host/render_widget_host.h +++ b/chrome/browser/renderer_host/render_widget_host.h @@ -5,7 +5,7 @@ #ifndef CHROME_BROWSER_RENDERER_HOST_RENDER_WIDGET_HOST_H_ #define CHROME_BROWSER_RENDERER_HOST_RENDER_WIDGET_HOST_H_ -#include <queue> +#include <deque> #include "app/gfx/native_widget_types.h" #include "base/process.h" @@ -365,7 +365,10 @@ class RenderWidgetHost : public IPC::Channel::Listener, // Called when we an InputEvent was not processed by the renderer. This is // overridden by RenderView to send upwards to its delegate. - virtual void UnhandledKeyboardEvent(const NativeWebKeyboardEvent& event) {} + // Returns true if the event was handled by its delegate. + virtual bool UnhandledKeyboardEvent(const NativeWebKeyboardEvent& event) { + return false; + } // Notification that the user has made some kind of input that could // perform an action. The render view host overrides this to forward the @@ -528,11 +531,12 @@ class RenderWidgetHost : public IPC::Channel::Listener, base::TimeTicks repaint_start_time_; // Queue of keyboard events that we need to track. - typedef std::queue<NativeWebKeyboardEvent> KeyQueue; + typedef std::deque<NativeWebKeyboardEvent> KeyQueue; // A queue of keyboard events. We can't trust data from the renderer so we // stuff key events into a queue and pop them out on ACK, feeding our copy // back to whatever unhandled handler instead of the returned version. + // See the description of |pending_key_events_| below for more details. KeyQueue key_queue_; // Set when we update the text direction of the selected input element. @@ -544,6 +548,42 @@ class RenderWidgetHost : public IPC::Channel::Listener, // NotifyTextDirection(). bool text_direction_canceled_; + // How many key events in |key_queue_| are not sent to the renderer yet, + // counted from the back of |key_queue_|. + // In order to suppress a Char event when necessary (see the description of + // |suppress_next_char_events_| below), we can't just send it to the + // renderer as soon as we get it. Instead, we need wait for the result of + // preceding RawKeyDown event back from the renderer, and then decide how to + // process the pending Char events according to the result. + // So if we get one or more Char events before receiving the result of + // preceding RawKeyDown event, we need keep them in |key_queue_|. And in + // order to keep the order the key events, all following key events must be + // pending until the pending Char events got processed. + size_t pending_key_events_; + + // Indicates if the next sequence of Char events should be suppressed or not. + // System may translate a RawKeyDown event into zero or more Char events, + // usually we send them to the renderer directly in sequence. However, If a + // RawKeyDown event was not handled by the renderer but was handled by + // our UnhandledKeyboardEvent() method, eg. as an accelerator key, then we + // shall not send the following sequence of Char events, which was generated + // by this RawKeyDown event, to the renderer. Otherwise the renderer may + // handle the Char events and cause unexpected behavior. + // For example, pressing alt-2 may let the browser switch to the second tab, + // but the Char event generated by alt-2 may also activate a HTML element + // if its accesskey happens to be "2", then the user may get confused when + // switching back to the original tab, because the content may already be + // changed. + bool suppress_next_char_events_; + + // During the call to some methods, eg. OnMsgInputEventAck, this + // RenderWidgetHost object may be destroyed before executing some code that + // still want to access this object. To avoid this situation, |death_flag_| + // shall be pointed to a local variable in the method, and then |*death_flag_| + // will be set to true when destroying this RenderWidgetHost object, then the + // method shall exit immediately when |*death_flag_| becomes true. + bool* death_flag_; + DISALLOW_COPY_AND_ASSIGN(RenderWidgetHost); }; |