Timeline

Jun 30, 2004:

7:07 PM Changeset in webkit [6954] by trey

• 14 edits in trunk

WebCore:

Dragging within a web view should be allowed to start when the window isn't key.

A few months ago, Chris made this work, but it relied on the fact that all dragging
was done in WebKit. When WebCore got involved in dragging, it was broken. Now we
have a new scheme that gets it working again that properly involves WebCore.

The general idea is that when AK asks us whether to accept the first mouse and do
"delayed window ordering", we must consult WC to see if we might start a drag. In
addition, instead of these drags in non-active windows being started as a special
case in WK, they go through the normal WK-WC drag machinery.

Reviewed by John.

• khtml/khtml_part.cpp: (KHTMLPart::shouldDragAutoNode): New x,y args.
• khtml/khtml_part.h:
• khtml/rendering/render_object.cpp: (RenderObject::draggableNode): Pass through new x,y args.
• khtml/rendering/render_object.h:
• kwq/KWQKHTMLPart.h: (KWQKHTMLPart::setActivationEventNumber): New setter.
• kwq/KWQKHTMLPart.mm: (KWQKHTMLPart::KWQKHTMLPart): Init new ivar. (KWQKHTMLPart::eventMayStartDrag): New routine that checks if we might start a drag in response to a mouseDown. (KWQKHTMLPart::khtmlMouseMoveEvent): Pass x,y to the routine that finds a draggable node. This eventually gets back up to WK's _mayStartDragAtEventLocation:. Delay requirement when dragging the selection now implemented here. (KWQKHTMLPart::khtmlMouseReleaseEvent): Must avoid changing the selection if we wind up here as part of the first click in a window (because we started handling the click to possible start a drag, but that never came through). (KWQKHTMLPart::mouseDown): Save away event timestamp. (KWQKHTMLPart::shouldDragAutoNode): Pass location up to WK instead of the most recent event we stashed.
• kwq/WebCoreBridge.h:
• kwq/WebCoreBridge.mm: (-[WebCoreBridge setActivationEventNumber:]): Trivial glue. (-[WebCoreBridge eventMayStartDrag:]): Ditto.

WebKit:

Dragging within a web view should be allowed to start when the window isn't key.

A few months ago, Chris made this work, but it relied on the fact that all dragging
was done in WebKit. When WebCore got involved in dragging, it was broken. Now we
have a new scheme that gets it working again that properly involves WebCore.

The general idea is that when AK asks us whether to accept the first mouse and do
"delayed window ordering", we must consult WC to see if we might start a drag. In
addition, instead of these drags in non-active windows being started as a special
case in WK, they go through the normal WK-WC drag machinery. Finally to work in
frames we have to drill to the deepest hit view in acceptsFirstMouse, because previous
hacks to hitTest make the top-most WebHTMLView field all events for its view tree
(which leads to it fielding all acceptFirstMouse messages too).

Reviewed by John.

• WebCoreSupport.subproj/WebBridge.m: (-[WebBridge mayStartDragAtEventLocation:]): Glue change for new arg type.
• WebView.subproj/WebHTMLView.m: (-[WebHTMLView _startDraggingImage:at:operation:event:sourceIsDHTML:DHTMLWroteData:]): firstMouseDownEvent ivar is no longer needed. (-[WebHTMLView _mayStartDragAtEventLocation:]): Receives a location instead of a drag event, since we need to do this work when we have no drag event. This means the check of the delay for text dragging is moved down to WebCore. (-[WebHTMLView acceptsFirstMouse:]): Respond based on whether we might do a drag. This includes drilling to the deepest view the event hits, whereas we used to only respond considering the topmost WebHTMLView. (-[WebHTMLView shouldDelayWindowOrderingForEvent:]): Ditto. (-[WebHTMLView mouseDown:]): Get rid of special case where some activating mouseDown events weren't sent to WC. We need to go through the whole pipeline now to get a drag started properly. (-[WebHTMLView mouseDragged:]): Ditto, let WC start the drag. (-[WebHTMLView mouseUp:]): firstMouseDownEvent ivar is no longer needed.
• WebView.subproj/WebHTMLViewInternal.h:
• WebView.subproj/WebHTMLViewPrivate.h:

10:14 AM Changeset in webkit [6953] by trey

• 2 edits in trunk/WebCore

Need to tighten up JS error checking for requesting drag props
in the wrong cases.

Reviewed by John.

• khtml/ecma/kjs_events.cpp: (Clipboard::getValueProperty): Assert if someone somehow set dropEffect or effectAllowed and it's a copy/paste clipboard instead of a dragging clipboard. (Clipboard::putValue): Don't let anyone set dropEffect or effectAllowed on a copy/paste clipboard. (ClipboardProtoFunc::tryCall): Disallow setting dragImage on a copy/paste clipboard.

Jun 29, 2004:

4:37 PM Changeset in webkit [6952] by trey

• 4 edits in trunk/WebCore

DHTML dragging - source should have access to the operation chosen
by the destination.

Reviewed by John

• kwq/KWQKHTMLPart.h:
• kwq/KWQKHTMLPart.mm: (KWQKHTMLPart::dragSourceEndedAt): Set the destination's operation on the clipboard.
• kwq/WebCoreBridge.mm: (-[WebCoreBridge dragExitedWithDraggingInfo:]): For completeness we set the source op for the ondragexit event. (-[WebCoreBridge concludeDragForDraggingInfo:]): Ditto for the drop event. (-[WebCoreBridge dragSourceEndedAt:operation:]): Pass through of operation.