Drags from HTML editor windows fail

RESOLVED FIXED

Status

()

Core
Editor
RESOLVED FIXED
13 years ago
12 years ago

People

(Reporter: Sachin, Unassigned)

Tracking

(Blocks: 1 bug, {fixed1.8})

Trunk
x86
OS/2
fixed1.8
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

13 years ago
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.
(Reporter)

Comment 1

13 years ago
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

13 years ago
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

13 years ago
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.
Severity: major → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: 4xp
Summary: Selecting the text in the composer using mouse and dragging it to move it doesnot work → [RFE] Drag and drop should work for text selections in composer and mail compose window
Product: Browser → Seamonkey

Comment 4

12 years ago
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

12 years ago
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
Severity: enhancement → normal
Component: Composer → Editor
Product: Mozilla Application Suite → Core
Summary: [RFE] Drag and drop should work for text selections in composer and mail compose window → Drags from HTML editor windows fail

Comment 6

12 years ago
Created attachment 196014 [details] [diff] [review]
fixes OS/2 drag failure in HTML editor

Comment 7

12 years ago
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

Updated

12 years ago
Attachment #196014 - Flags: superreview?(bryner)
Attachment #196014 - Flags: review+

Comment 8

12 years ago
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

12 years ago
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.
Attachment #196014 - Attachment is obsolete: true
Attachment #196389 - Flags: review?(mozilla)

Comment 10

12 years ago
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

12 years ago
(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

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

r=mkaply
Attachment #196389 - Flags: review?(mozilla) → review+

Updated

12 years ago
Attachment #196014 - Flags: superreview?(bryner)

Comment 13

12 years ago
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

12 years ago
(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.

Updated

12 years ago
Blocks: 314605

Comment 15

12 years ago
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. :-)
No longer blocks: 314605

Updated

12 years ago
Blocks: 314605

Comment 16

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

OS/2 only #ifdef
Attachment #196389 - Flags: approval1.8rc2?

Comment 17

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

OS/2 Only - approved to land
Attachment #196389 - Flags: approval1.8rc2? → approval1.8rc2+

Updated

12 years ago
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.