Lines Matching full:mouse
2419 Since Java depends on doing a hit test inside it's mouse moved handling, let hit testing on Java
3345 Mouse clicks ignored in inline input areas
3348 (-[NSArray mouseDown:]): Removed misleading comment and added code to send mouse event to input manager.
3349 (-[NSArray mouseDragged:]): Added code to send mouse event to input manager.
3904 the form's url when you mouse over a submit button.
4028 "Editing delegate selection methods not called when using mouse"
6321 - fixed <rdar://problem/3655817> please add support for mouse wheel events and the onmousewheel handler
8158 - fixed <rdar://problem/3964972> update _initWithCGSEvent:eventRef: call in mouse moved workaround (breaks cursors in Carbon WebKit applications)
8638 under the mouse in a toolTip. I tested this in Safari, but we're adding this
9148 field since that field is set up too early in the mouse down event handling process.
9242 concert to track the mouse and determine a drop location, respectively. However, moveDragCaretToPoint:
9859 - fixed <rdar://problem/3857151> Assertion failure in "trackingRectOwner" while moving mouse over Slashdot.org page
10889 (-[WebHTMLView _delegateDragSourceActionMask]): removed temp fix, assert that the mouse event is not nil
10911 (-[WebHTMLView _delegateDragSourceActionMask]): return none if the mouse down event is nil
10965 link dragging if the element under the mouse pointer is
12027 <rdar://problem/3764856> REGRESSION !25-154): Safari accepts mouse clicks (follows links) when not key
12033 (-[WebHTMLView acceptsFirstMouse:]): only call eventMayStartDrag if _isSelectionEvent returns YES since we only want to allow selection dragging on the first mouse down
13119 Fixed: <rdar://problem/3720728> REGRESSION (125.8-146): Crash moving mouse over plugin at manray-photo.com
13308 The general idea is that when AK asks us whether to accept the first mouse and do
13495 This part fixes the ondrag coords. I thought Cocoa passed us the mouse location
13497 WebCore needs the mouse location, so to calc that we must save away the
13498 offset of the mouse relative to the image when we kick off the drag.
14383 Fixed this problem by using NSTextView's approach of only allowing dragging on first mouse down.
14388 mouse down
14389 (-[WebHTMLView mouseDown:]): Don't tell WebCore about the first mouse down event since only dragging can occur on the first mouse down.
14390 (-[WebHTMLView mouseDragged:]): Don't tell WebCore about the drags that occur after the first mouse down since only dragging can occur after the first mouse down.
16741 Pass modifier flags always, not just for mouse events. This fixes 3601604.
16930 mouse moved event to be correct.
20489 Ensure that the autoscroll timer is always stopped if a mouse up event is lost.
20661 under the mouse is voiced.
21065 - fixed 3127833 -- autoscroll only works when mouse is moving
21069 the case where a view is removed from the view hierarchy while the mouse is down.
21078 (-[WebHTMLView _autoscroll]): Check for a mouse up event in the queue; if one is
21079 there, then no autoscrlling. But if not, then create a fake mouse dragged event
21086 - worked around 3429631 -- window stops getting mouse moved events after first tooltip appears
21857 (-[WebHTMLView mouseDown:]): Don't send a mouse down event in the case where we
23146 if you used the scroll wheel while moving the mouse, bug 3245425.
23366 right mouse up event, and pass that to menuForEvent: and _popUpMenuWithEvent.
23762 - fixed 3277675 -- REGRESSION: mouse wheel events not coalesced
24302 - fixed 3264980: Carbon support in WebKit needs to route mouse events properly
25541 types. Mouse moved events are particularly bad because they have deltaX/Y/Z and the
28059 view, tell it that the mouse moved outside everything in the view,
28061 confused). This makes cross-frame mouse enter/leave work properly.
30273 - fixed 3010915 -- mouse wheel won't scroll the main document when you are over [i]frame
32570 without checking if the mouse is down (WC deals with that now). That fixes 2940179,
32813 During AK dragging the system takes over the event stream and we never get any mouse
33495 The new logic in WebCore is slightly pickier, and can't abide a mouse-moved event
33496 coming in during a drag. Unfortunately, we were sending a fake mouse-moved event
33500 (-[WebHTMLView mouseDown:]): Cancel any scheduled fake mouse-moved event.
33501 (-[WebHTMLView mouseUp:]): Send a fake mouse-moved event because we didn't update during the drag.
33504 Don't schedule a fake mouse-moved event if the mouse is down, because that means we are in the
33547 mouse up as if it were a mouse move).
34487 Check the control key in the mouse down event. If it's down, then do no magic.
34493 - fixed 3128651 -- REGRESSION: Mouse wheeling is busted on frames pages
34496 Only do the hitTest magic for left mouse downs; the rest of the clicks end up going
34734 or from calls back from WebCore once we begin mouse-down event handling.
34745 doing it right away. If we do it right away, we might reenter because sending a mouse moved event
34746 can result in another layout since mouse moved events are the same as mouse dragged events in KHTML.
34830 you can set a global and do a normal hit test, needed for the mouse-moved handling below. Also,
34832 and ignoring the result. The sum total is that it always returns self for mouse-moved events, so
34946 frame resize bar intercepts mouse clicks
35050 WebCore now handles getting the mouse events to the subviews after passing
35389 Allow mouse up events too. Those are usually the ones that trigger navigation.
35437 - update NSEvent handling in preparation for NSView mouse event handling going through WebCore
35443 a mouse down event. This prevents trouble when we have other kinds of events coming through.
