50703 - After double-click that launches dialog, mouse up on dialog button triggers dragNdrop in content window

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Charles Manske]

In Composer start a page and enter in enough text with returns to have many
lines (or just load a large page, such as via the debug menu, "Composer with
test page").
Near the top of the document, click in some text.
Click on the HLine toolbar button to insert an HR tag.
Double click on that HR -- that will select it and launch the "Horizontal Line
Properties" dialog. Move the dialog so the OK button is lower on the screen 
than the HR in the page. Click on either Ok or Cancel buttons and wait...
You will see the HR move from where it was to a location lower in the page!
What is happening is that the "mouseup" event during the dialog button click
is going to the parent document. It thinks that the user dragged the selected
HR from its original location to location in the document where the mouseup 
occured. 
I discussed this with saari and he thinks it is a dup, but in this case the 
effects are very damaging -- it radically changes the contents in a user's 
document.

Comment 1

[Charles Manske]

Nominating for nsbeta3: This renders double-clicking on objects in the editor
completely broken -- documents are mangled.
It happens for any object: Horizontal Line, image, named 
anchor, link, table cell, form elements, etc. Double clicking on an object to 
edit its properties is an important feature that worked in 4.x.
It reveals a serious problem in event handling -- the mouseup event on a dialog 
button should never go to the parent window!

Comment 2

[rubydoo123]

this happened to me today, when I selected cancel on the active dialog, the 
content that I had selected in the document was cut and pasted to where the 
cancel button was relative to the page. I had no idea that it even happened 
until I started to proof what I had written -- really weird.

Comment 3

[rubydoo123]

*** Bug 50607 has been marked as a duplicate of this bug. ***

Comment 4

[rubydoo123]

*** Bug 50263 has been marked as a duplicate of this bug. ***

Comment 5

[Nisheeth Ranjan]

Marking nsbeta3-.  Workaround is to use the context menu to bring up the 
properties dialog, right?

Comment 6

[saari (gone)]

This is another event transition bug. Tom has many of these in different forms.
This one is interesting because the resulting behavior is pretty strange.

Comment 7

[Charles Manske]

I disagree with Nisheeth's evaluation. Beppe has seen this behavior without 
double clicking (see 50607 and 50263).
I think it's a serious event problem. Mouse events should never get "lost" 
to randomly float to a dialog's parent!
Please reconsider.

Comment 8

[Charles Manske]

Ok, I'm trying to help so I examined this thoroughly.
50263 is a real dup, 50607 is probably not related at all.
So what's happening is that after the dialog closes, the editor's 
drag listener is getting a spurious DragGesture event. The drag event's 
target node is the selected object. There's a comment in our code that we
"should be checking the XY coordinates of the mouseevent", which is correct,
but this is another case where our mouse event interfaces are lacking -- 
we cannot get the proper coordinate space to ask "where is the mouse relative
to a particular DOM object." So instead all we can do is ask if the target
node is inside the selection, which in this case is misleading since the mouse
isn't anywhere near the selected object and thus we start a drag even though the
mouse isn't being moved over the selected object.
This seems to be happening only after a double click. Note that when the editor 
mouse listener launches the dialog during a MouseDown event (testing for 
clickCount = 2) and then calls mouseEvent->PreventDefault() *after* the 
returning from dialog code. Also interesting is that after clicking on OK or 
Cancel button, the dialog actually doesn't respond until mouse is moved 
slightly, so it is a mouse move event that allows dialog to close, but then 
generates the bad drag event. So there must be something wrong in the logic that 
determines if a drag gesture call should be made instead of normal mouse move.
(Maybe when the dialog is up, the even code thinks the mouse is down when it
shouldn't?)
I've figured out how to block this behavior with an ugly kludge: setting a 
state flag in the editor when we do a double click so the "CanDrag" query 
returns FALSE the next time it is called.
With that we can live with this bug, but we it is not very nice having to add 
another method to nsIHTMLEditor(SetCanDrag()) just for this purpose. But I don't 
want to give up being able to double click on objects!
I would be very interested to know if this problem exists on Mac and Linux,
since I recall from 4.x code that Windows issues a spurious mouse move message
after a dialog closes, so if it's only on windows, that may help find the 
real problem.

Comment 9

[rubydoo123]

*** Bug 50578 has been marked as a duplicate of this bug. ***

Comment 10

[Charles Manske]

I found a workaround for this problem so the "spurious" drag event is ignored
in Composer. This has been reviewed by Nisheeth and will be checked in asap.
This will release the pressure to fix this for nsbeta3 (or 6.0, for that matter)

Comment 11

[Charles Manske]

The workaround for Composer is checked in.

Comment 12

[Nisheeth Ranjan]

In light of Charley's workaround for the editor, minusing and futuring.

Comment 13

[rubydoo123]

*** Bug 53257 has been marked as a duplicate of this bug. ***

Comment 14

[Loco]

Updating QA Contact.

Comment 15

[Gervase Markham [:gerv]]

Now that the workaround's in, does this need a relnote of some sort?

The blurb:
It seems unclear to me whether this bug requires either of a "developer" or 
"user" release note for Netscape 6 RTM. If anyone feels it does, can they please 
draft one and then nominate with the relnote-user or relnote-devel strings in 
the Status Whiteboard.

Thanks :-)

Gerv

Comment 16

[Loco]

Changing Status for my reference.  Was NSBETA3-.  Anyone think this 
should be renominated?

Comment 17

[Charles Manske]

The work-around is definitely an ugly kludge. In the spirit of making thinks
work correcly, I urge that this be fixed. See my comments from 8/31/00

Comment 18

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 19

[Madhur Bhatia]

QA contact updated

Comment 20

[rubydoo123]

removing myself from the cc list

Comment 21

[Simon Fraser [no longer active]]

What's up with this bug? We need to fix it to be able to clean up the editor
APIs for embedding.

Comment 22

[Marek Z. Jeziorek]

this is a high priority for the next release.  this bug needs to land for
mozilla 1.1, 1.2, 1.3 as per edt triage meeting.

Comment 23

[saari (gone)]

topembed+, a general issue we should try to get fixed

Comment 24

[Brian Ryner (not reading)]

I'm trying to come up with an HTML testcase for this where I have a double-click
handler on an element call alert(), but I'm not seeing the behavior described.

Comment 25

[saari (gone)]

odd that this doesn't show up in an html test case. Any reasons why this might
be XUL specific?

Let's get a test case if possible

Comment 26

[Michael Buckland]

Discussed in edt.  Minusing.

Comment 27

[Wayne Mery (:wsmwk)]

WFM 
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.15) Gecko/20080615 SeaMonkey/1.1.10