Closed
Bug 336241
Opened 19 years ago
Closed 19 years ago
canDrop isn't called when just the drag and drop action changes
Categories
(Core :: DOM: Copy & Paste and Drag & Drop, defect)
Core
DOM: Copy & Paste and Drag & Drop
Tracking
()
RESOLVED
FIXED
People
(Reporter: standard8, Assigned: standard8)
References
Details
(Keywords: fixed1.8.1)
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
neil
:
review+
roc
:
superreview+
bryner
:
approval-branch-1.8.1+
|
Details | Diff | Splinter Review |
Whilst trying to implement some new Drag & Drop functionality in address book, I found some problems with the drag and drop code in trees.
Currently, when you drag an address book item over an address book, as the mouse reaches the address book then canDrop is queried with the current action state. However if you then keep the mouse still and change the drag action by pressing a modifier key canDrop isn't re-queried.
I need this as in some cases within address book a copy should be allowed, but a move isn't. With the functionality as it is, it will cope, however the graphics aren't updated appropriately to inform the user as to what is actually happening.
The problem is that in nsTreeBodyFrame::HandleEvent (http://lxr.mozilla.org/seamonkey/source/layout/xul/base/src/tree/src/nsTreeBodyFrame.cpp#2016) it filters out changes where the mouse hasn't moved, but doesn't take into account the drag action.
I have a patch in progress for this and will attach it later.
Assignee | ||
Comment 1•19 years ago
|
||
This patch adds a value to Slots so that the drag action of the last call to HandleEvent is tracked and then is used in the comparison for changes to see if just the drag action has changed.
If you wish to test it, at the moment I think the best way is find a drag & drop case for a tree where you can insert some text output into canDrop and then start to involke a drag to the point where canDrop is queried. Keep the mouse where it is and use the modifier keys to change the drag action - you should see the text output coming out as well.
Attachment #220525 -
Flags: review?(bzbarsky)
Comment 2•19 years ago
|
||
I'm not qualified to review this code, at least if you want a review sometime this month; I'd try someone like Neil, perhaps...
Assignee | ||
Comment 3•19 years ago
|
||
Comment on attachment 220525 [details] [diff] [review]
Keep track of the last drag action and add it to the list of checks for changes
(In reply to comment #2)
> I'm not qualified to review this code, at least if you want a review sometime
> this month; I'd try someone like Neil, perhaps...
>
Thanks for letting me know. Trying Neil...
Attachment #220525 -
Flags: review?(bzbarsky) → review?(neil)
Comment 4•19 years ago
|
||
Comment on attachment 220525 [details] [diff] [review]
Keep track of the last drag action and add it to the list of checks for changes
>+ * Mark Banner <mark@stnadard8.demon.co.uk>
:-P
> nsCOMPtr<nsIDragSession> dragSession;
Hey, is this line unused? ;-)
> PRInt16 lastDropOrient = mSlots->mDropOrient;
> PRInt16 lastScrollLines = mSlots->mScrollLines;
>
>+ // Find out the current drag action
>+ PRUint32 currentDragAction = mSlots->mLastDragAction;
>+ if (mSlots->mDragSession)
>+ mSlots->mDragSession->GetDragAction(¤tDragAction);
I think you're going about this the wrong way around. As the two lines of context demonstrate, your temporary variable should be the last value, and the Slots member should be named mDragAction.
> PRInt16 mDropOrient;
>
>+ // The last drag action that was received for this slot
>+ PRUint32 mLastDragAction;
>+
> // Number of lines to be scrolled.
> PRInt16 mScrollLines;
Putting a 32 between two 16s is not good. Here's the layout on a PPC:
NN NN NN NN mDropRow
NN NN XX XX mDropOrient
NN NN NN NN mDragAction
NN NN XX XX mScrollLines
NN NN NN NN mDragSession
As you can see, you just required 8 extra bytes instead of 4. Try this:
NN NN NN NN mDropRow
NN NN mDropOrient
NN NN mScrollLines
NN NN NN NN mDragAction
NN NN NN NN mDragSession
Attachment #220525 -
Flags: review?(neil) → review-
Assignee | ||
Comment 5•19 years ago
|
||
Updated patch to address Neil's comments.
Attachment #220525 -
Attachment is obsolete: true
Attachment #220685 -
Flags: review?(neil)
Comment 6•19 years ago
|
||
Comment on attachment 220685 [details] [diff] [review]
Keep track of the last drag action and add it to the list of checks for changes v2
Looks good now.
Attachment #220685 -
Flags: review?(neil) → review+
Assignee | ||
Updated•19 years ago
|
Attachment #220685 -
Flags: superreview?(roc)
Attachment #220685 -
Flags: superreview?(roc) → superreview+
Assignee | ||
Comment 7•19 years ago
|
||
Patch checked into trunk -> fixed.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 8•18 years ago
|
||
Comment on attachment 220685 [details] [diff] [review]
Keep track of the last drag action and add it to the list of checks for changes v2
Requesting branch approval for this patch. I'd like to get it in as it provides the required functionality for the first address book drag and drop patch on bug 35837.
Its been on trunk for about a week now and no one's raised any regressions as far as I can see.
I'm hoping to get both patches on that bug in for Thunderbird 2.0/SeaMonkey 1.1 but this bug will block either of them going in.
Attachment #220685 -
Flags: approval-branch-1.8.1?(bryner)
Updated•18 years ago
|
Attachment #220685 -
Flags: approval-branch-1.8.1?(bryner) → approval-branch-1.8.1+
You need to log in
before you can comment on or make changes to this bug.
Description
•