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




Event Handling
17 years ago
8 years ago


(Reporter: Charles Manske, Unassigned)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbetadenied])



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

Comment 1

17 years ago
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!
Keywords: nsbeta3

Comment 2

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

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

Comment 4

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

Comment 5

17 years ago
Marking nsbeta3-.  Workaround is to use the context menu to bring up the 
properties dialog, right?
Keywords: relnote
Whiteboard: [nsbeta3-]

Comment 6

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

17 years ago
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.
Whiteboard: [nsbeta3-]

Comment 8

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

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

Comment 10

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

17 years ago
The workaround for Composer is checked in.

Comment 12

17 years ago
In light of Charley's workaround for the editor, minusing and futuring.
Whiteboard: [nsbeta3-]
Target Milestone: --- → Future

Comment 13

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

Comment 14

17 years ago
Updating QA Contact.
QA Contact: janc → lorca
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 :-)


Comment 16

17 years ago
Changing Status for my reference.  Was NSBETA3-.  Anyone think this 
should be renominated?
Whiteboard: [nsbeta3-] → [nsbetadenied]

Comment 17

17 years ago
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
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok

Comment 19

16 years ago
QA contact updated
QA Contact: gerardok → madhur

Comment 20

16 years ago
removing myself from the cc list

Comment 21

16 years ago
What's up with this bug? We need to fix it to be able to clean up the editor
APIs for embedding.
Keywords: relnote → topembed
OS: Windows NT → All
Hardware: PC → All

Comment 22

16 years ago
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.
Keywords: topembed → topembed-


16 years ago
QA Contact: madhur → rakeshmishra

Comment 23

15 years ago
topembed+, a general issue we should try to get fixed
Assignee: joki → bryner
Keywords: topembed- → topembed+


15 years ago
QA Contact: rakeshmishra → trix
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

15 years ago
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
Target Milestone: Future → mozilla1.4beta

Comment 26

15 years ago
Discussed in edt.  Minusing.
Keywords: topembed+ → topembed-
Assignee: bryner → events
QA Contact: trix → ian
Target Milestone: mozilla1.4beta → ---
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20080615 SeaMonkey/1.1.10
Assignee: events → nobody
Last Resolved: 8 years ago
QA Contact: ian → events
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.