243270 - Drags from HTML editor windows fail

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Sachin]

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7b) Gecko/20040422
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7b) Gecko/20040422

The problem is not seen in Mozilla on Windows. The problem occurs on Moz14
as well as Moz16 on OS/2.


Reproducible: Always
Steps to Reproduce:
1. Press ctrl+4 in the browser window to open a composer.
2. Input some texts in the composer.
3. Select a letter or a word using a mouse. 
4. Drag the selected letter/word keeping the left mouse button pressed and move
it a new location using the mouse.

Actual Results:  
The selected letter/word is not moved to the new location of the mouse.

Expected Results:  
The selected letter/word should be moved to the new location of the mouse within
the composer.

Comment 1

[Sachin]

The problem doesnot happen on NetScape-461 for OS/2. Looks like the drag drop
code for the texts in Composer is not written for Mozilla.

Comment 2

[Rich Walsh]

AFAIK, dragging text from any editor window that supports HTML composition has
never been possible in the OS/2 version.  This affects not only Composer, but
possibly more importantly, email editor windows as well.  Dropping text, files,
etc. into these windows is supported, as is both drag & drop in simple editor
windows that only support plain-text.  The last time I looked (many months ago),
I believe HTML editor windows were failing to invoke nsDragService.  The next
time I do a debug build I will add some code to nsDragService to confirm this.

BTW... on OS/2, one drags with the right mouse button (a.k.a. MB2).

Comment 3

[Peter Weilbacher]

Yes, this indeed does not work,
Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8a5) Gecko/20041116.
Still, I don't understand why it doesn't work. http://www.mozilla.org/editor/
explains that the URL bar, the composer and other editing controls use the same
basic code. Yet drag-and-drop work in the URL bar and e.g. in the change mode of
wikipedia, but not in composer or mail editor. Well, I guess i should have a
look at the code...

But as Rich said, this has never worked in Mozilla, so I am changing this into
enhancement.

Comment 4

[Peter Weilbacher]

Kim Ludvigsen's newsgroup posting just reminded me of this problem, d&d doesn't
with with NVU, either.

Rich, do you by any chance have a recent debug build lying around which you can
use to take a look? :-)

Comment 5

[Rich Walsh]

This Bugzilla entry identifies a bug in xp code, not an enhancement to OS/2 code.

When nsHTMLEditorMouseListener.cpp gets a right mouse button down event, it 
suppresses further processing of the event.  This triggers a hack in
nsEventStateManager.cpp which cancels the tracking of drag gestures. 
Consequently, RMB drags aren't recognized as such.  Since other platforms drag
with the left button, the problem is only seen on OS/2.

My patch fixes this with an "#ifdef XP_OS2" that bypasses the offending line of
code.  AFAICT, eliminating it has no negative effect & I suspect it's
unnecessary on any platform.  However, since I can't test this, I've taken the
more conservative OS/2-only approach.

FWIW... the hack in nsEventStateManager appears to be needed for other reasons &
can't be eliminated.  See Bug #43258

Comment 6

[Rich Walsh]

Attachment: fixes OS/2 drag failure in HTML editor

Comment 7

[Rich Walsh]

Mike, can you review this or can you identify someone who should review it?

Peter, can you add this to Nvu to see if it has any unexpected consequences?

Thanks

Comment 8

[Peter Weilbacher]

It seems to help the problem in NVU and I didn't notice any side effects while
doing some quick testing. I put up a fixed nvu.exe, let's see if someone complains.

I also patches this in SeaMonkey on Linux and I didn't see any side effects
after removing "mouseEvent->PreventDefault();"  from the "if (isContextClick)"
case. But I haven't done much testing on that yet.

Comment 9

[Rich Walsh]

Attachment: revision to enable dragging both images & text

The previous patch enabled text drags but did nothing for images.  This enables
both without any untoward effects.

Comment 10

[Peter Weilbacher]

Yes, this works in NVU even better, and image can now be dragged and dropped
(they are still always copied). However, it does not work the way I would have
expected it to. I can d&d the images, but the copied image never appears as
such, just the alt-text is shown, although the source seems to be correct.
Weird, I have to do some more testing.

(At first, I also wondered how users who set d&d on OS/2 to work with
mousebutton 1 would react with this patch, but Mozilla does not support anything
else than button 2 anyway, right? And as nobody complained about that I guess
that these users don't exist.)

Comment 11

[Rich Walsh]

(In reply to comment #10)
> However, it does not work the way I would have expected it to. I can d&d
> the images, but the copied image never appears as such, just the alt-text

I did my testing primarily with Thunderbird's message compose window & bit with
Seamonkey's Composer.  Both worked as expected:  the photo is moved & displayed.
 I just tried Composer again using an image dragged from a webpage;  this time I
did a copy ^got a 2nd copy of the image.  Overall, it seems like an Nvu issue.

Comment 12

[Mike Kaply [:mkaply]]

Comment on attachment 196389 [details] [diff] [review]
revision to enable dragging both images & text

r=mkaply

Comment 13

[Peter Weilbacher]

Is there any chance to update the patch so that one can use modifier keys to control the behavior of how the d&d is handled? Currently, in SeaMonkey composer everything is moved (even when Ctrl is pressed and the mouse pointer changes to indicate a copy operation, or if Ctrl-Shift is pressed and the mouse changes to a link indicator). ::NativeDrop checks for the Alt key using isAlt, but none of the other keys is checked. Would this need to be added to DRM_ATOM in that function?

Comment 14

[Rich Walsh]

(In reply to comment #13)
> Is there any chance to update the patch so that one can use modifier keys
> to control the behavior of how the d&d is handled?

Do other platforms exhibit the same behavior?

> ::NativeDrop checks for the Alt key using isAlt, but none of the other keys
> is checked.

Alt is used as a platform-specific "flavor" modifier.  It determines whether the native code should describe a file as a URL or as a block of text (i.e. the file's contents).

The other keys don't modify the meaning of the drop, only the action to be taken (i.e. move/copy/link)  This has to be handled by the target of the drop because the native code has no way of determining whether a given action is appropriate or will even be recognized.  Getting this fixed should be addressed in a separate bug report.

Comment 15

[Peter Weilbacher]

Yes, on Windows and Linux (as reported in the newsgroup and tested by me, resp.) Ctrl let's the user copy the dragged object. I opened bug 314605 for this purpose and for now assigned it to you. :-)

Comment 16

[Mike Kaply [:mkaply]]

Comment on attachment 196389 [details] [diff] [review]
revision to enable dragging both images & text

OS/2 only #ifdef

Comment 17

[Mike Schroepfer]

Comment on attachment 196389 [details] [diff] [review]
revision to enable dragging both images & text

OS/2 Only - approved to land