[chromium-dev] Re: Preventing keypress after accellerator?
On Fri, Nov 6, 2009 at 6:51 PM, James Su su...@chromium.org wrote: One example: the default behavior of Ctrl+M keypress event is insertNewLine, and it'll always be performed in editor_client_impl.cc if the keypress event is not handled or prevented by the web app. Then the result is we can never use Ctrl+M as an browser accelerator. Is above explanation clear enough? If we're in an editable area, wouldn't we _want_ ctrl-m to insert a new line, and ctrl-b to toggle bold, etc.? The description above sounds desirable rather than problematic. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Preventing keypress after accellerator?
2009/11/8 Peter Kasting pkast...@google.com On Fri, Nov 6, 2009 at 6:51 PM, James Su su...@chromium.org wrote: One example: the default behavior of Ctrl+M keypress event is insertNewLine, and it'll always be performed in editor_client_impl.cc if the keypress event is not handled or prevented by the web app. Then the result is we can never use Ctrl+M as an browser accelerator. Is above explanation clear enough? If we're in an editable area, wouldn't we _want_ ctrl-m to insert a new line, and ctrl-b to toggle bold, etc.? The description above sounds desirable rather than problematic. ctrl-b behaves exactly like what you said, because the toggle bold action is bound to its key down event. If we want ctrl-m to behave like it as well, we can add an entry in keyDownEntries in editor_client_impl.cc to achieve it. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Preventing keypress after accellerator?
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. -- erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Preventing keypress after accellerator?
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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Preventing keypress after accellerator?
On Thu, Nov 5, 2009 at 10:49 PM, Erik Arvidsson a...@chromium.org wrote: On Thu, Nov 5, 2009 at 17:58, James Su su...@chromium.org wrote: 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. In what way do you disagree? Just saying Firefox and Safari do x alone doesn't mean x is right or sensical. You didn't actually give a reason why James' description is illogical. In the abstract it seems correct to me that if the browser handles something, it should not then also send it to the webpage. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Preventing keypress after accellerator?
You might want to read http://crbug.com/21624 first. It's the root cause for this change. I chose to fix that issue in such a generic way, because it's much more elegant than dealing with specific key bindings. If you encountered any issues caused by this change, please report them then let's think about how to deal with them. Regards James Su 2009/11/6 Erik Arvidsson a...@chromium.org 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. Why don't you consider it's an issue of firefox and Safari? And actually, Safari on Windows does prevent the keypress after a command. 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 -~--~~~~--~~--~--~---
