On Thu, Nov 5, 2009 at 17:58, James Su <su...@chromium.org> wrote:
> You may refer to following bug reports:
> http://crbug.com/21624
> http://crbug.com/21471
>
> 2009/11/6 Erik Arvidsson <a...@chromium.org>
>
> We have code to suppress the keypress event if keydown triggered a browser
>> accelerator both inside and outside of WebKit. I don't understand why we
>> want to prevent a keypress after a Ctrl+A or Ctrl+B keydown?
>>
> Because Ctrl+A and Ctrl+B are special key accelerators which will be
> handled by the WebKit or the Browser. For example, Ctrl+B is for toggling
> bookmark bar. When pressing Ctrl+B, the key down event will be sent to the
> WebKit first, then it'll be forwarded to the Browser if the WebKit didn't
> handle or prevent it. Then the Browser will handle it and open or close the
> bookmark bar. Then if we still send the key press event of Ctrl+B to the
> WebKit, it might be handled by some javascript code in the web page and
> perform a specified action. Then the user will notice that two actions were
> triggered by pressing Ctrl+B. In most time, such behavior will confuse the
> user. Especially if the key triggers tab switching or other dramatic UI
> change.
>
I don't really agree with that argument. Neither Firefox nor Safari prevents
the keypress after a command. IE just don't fire keypress events for
Ctrl+Key with some exceptions.
We don't send Ctrl+n, Ctrl+t nor Ctrl+w to the render view which I'm not
considering changing. These should not be sent to the current view since
they all remove or moves the user to a new view.
>
>> --
>> erik
>>
>> >>
>>
>
--
erik
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
