| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
EventDispatchDetails::target_destroyed
BUG=342867
TEST=EventDispatcherTest.*
Review URL: https://codereview.chromium.org/169963005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@253459 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Start converting the RootWindowHostDelegate implementations for event-dispatch
use the EventProcessor interface under-the-hood to allow easy transition to the
new dispatch process.
This patch makes this change for Key and Scroll events.
BUG=318879
R=ben@chromium.org
Review URL: https://codereview.chromium.org/113283005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240683 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
EventSource receives events from the native platform (e.g. X11), and dispatches
the event to an EventProcessor. The EventProcessor has access to a tree of
EventTargets, and it uses the appropriate EventTargeter to find the EventTarget
the event should be dispatched to, and then dispatches the event to the target.
More details at the doc linked to at the bug.
This patch also introduces a default implementation for the EventTargeter
interface.
BUG=318879
R=ben@chromium.org
Review URL: https://codereview.chromium.org/100643002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@239047 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dispatching an event can end up destroying the event-target, or the
event-dispatcher. So whenever an event is dispatched, look at the
EventDispatchDetails to ensure that the dispatcher/target is still alive before
doing anything with them.
BUG=none
R=sky@chromium.org
Review URL: https://codereview.chromium.org/63743002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@233772 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When capture is held all mouse events go to the captured window, even
if another window happens to be under the mouse. This patch makes it
so that when capture is held TooltipController looks for the window
under the mouse and potentially queries it for the tooltip.
If the window under the mouse differs from the captured window it is
queried for the tooltip if the capture window and the window under the
mouse have the same value for the window property
TooltipManager::kGroupingPropertyKey. The only place that sets this
value is menus. When a menu is shown only the first menu has
capture. By picking up the tooltip from the other menus tooltips
show correctly for nested menus.
I also had to update TooltipManagerAura to similarly update the
tooltip on the associated window when capture is held.
BUG=310604 5246 311291
TEST=see bug
R=varunjain@chromium.org
Review URL: https://codereview.chromium.org/40403004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@231452 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
| |
BUG=none
R=ben@chromium.org
Review URL: https://codereview.chromium.org/24413002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@225109 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
BUG=none
TEST=none
R=ben@chromium.org
TBR=brettw@chromium.org, scherkus@chromium.org, ananta@chromium.org,
Review URL: https://codereview.chromium.org/23851041
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@223906 0039d316-1c4b-4281-b951-d872f2087c98
|
