tree: 261dab9e9de4aadd40a686a13f960a47c05ffcfd [path history] [tgz]
  1. DEPS
  2. OWNERS
  3. README.md
  4. accelerator_commands.cc
  5. accelerator_commands.h
  6. accelerator_commands_unittest.cc
  7. accelerator_confirmation_dialog.cc
  8. accelerator_confirmation_dialog.h
  9. accelerator_controller_impl.cc
  10. accelerator_controller_impl.h
  11. accelerator_controller_unittest.cc
  12. accelerator_filter_unittest.cc
  13. accelerator_ids.h
  14. accelerator_table.cc
  15. accelerator_table.h
  16. accelerator_table_unittest.cc
  17. accelerator_unittest.cc
  18. ash_focus_manager_factory.cc
  19. ash_focus_manager_factory.h
  20. debug_commands.cc
  21. debug_commands.h
  22. exit_warning_handler.cc
  23. exit_warning_handler.h
  24. key_hold_detector.cc
  25. key_hold_detector.h
  26. magnifier_key_scroller.cc
  27. magnifier_key_scroller.h
  28. magnifier_key_scroller_unittest.cc
  29. pre_target_accelerator_handler.cc
  30. pre_target_accelerator_handler.h
  31. spoken_feedback_toggler.cc
  32. spoken_feedback_toggler.h
  33. spoken_feedback_toggler_unittest.cc
ash/accelerators/README.md

This directory contains code for handling accelerators in Ash. The following documents the flow of accelerators.

  1. wm::AcceleratorFilter() sees events first as it's a pre-target handler on Shell.
  2. wm::AcceleratorFilter calls to PreTargetAcceleratorHandler.
  3. PreTargetAcceleratorHandler handles accelerators that need to be handled early on, such as system keys. This does not include accelerators such as control-n (for new window).
  4. If focus is on a Widget, then views handles the accelerator.
  5. Views does normally processing first (meaning sends to the focused view). If the focused view doesn't handle the event, then Views sends to the FocusManager.
  6. FocusManager::OnKeyEvent() calls PostTargerAcceleratorHandler::ProcessAccelerator().
  7. PostTargerAcceleratorHandler::ProcessAccelerator() calls to Ash's AcceleratorController.

Steps 1-3 give Ash the opportunity to have accelerators before the target (these are often referred to as pre-target accelerators). Step 4-5 allows the target to handle the accelerator. Step 6-7 allow for post-target accelerators (accelerators that only occur if the target does not handle the accelerator).

Steps 4-7 differ if focus is on a remote window (a window created at the request of a client connecting by way of the WindowService). If focus is on a remote window, then step 4-7 are replaced with:

  1. WindowService waits for response from remote client.
  2. If remote client does not handle the event, WindowService calls WindowServiceDelegate::OnUnhandledKeyEvent().
  3. Ash's WindowServiceDelegateImpl::OnUnhandledKeyEvent() calls to AcceleratorController::Process(), which handles the post-target processing phase.