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.
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.
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).
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.
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? :-)
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
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
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.
Created attachment 196389 [details] [diff] [review] 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.
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.)
(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 on attachment 196389 [details] [diff] [review] revision to enable dragging both images & text r=mkaply
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?
(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.
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 on attachment 196389 [details] [diff] [review] revision to enable dragging both images & text OS/2 only #ifdef
Comment on attachment 196389 [details] [diff] [review] revision to enable dragging both images & text OS/2 Only - approved to land