Last Comment Bug 50703 - After double-click that launches dialog, mouse up on dialog button triggers dragNdrop in content window
: After double-click that launches dialog, mouse up on dialog button triggers d...
Status: RESOLVED WORKSFORME
[nsbetadenied]
: topembed-
Product: Core
Classification: Components
Component: Event Handling (show other bugs)
: Trunk
: All All
: P3 normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andrew Overholt [:overholt]
Mentors:
: 50263 50578 50607 53257 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2000-08-29 13:38 PDT by Charles Manske
Modified: 2009-04-29 14:41 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Charles Manske 2000-08-29 13:38:02 PDT
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 2000-08-29 13:43:39 PDT
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 2000-08-29 17:22:30 PDT
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 2000-08-30 15:43:55 PDT
*** Bug 50607 has been marked as a duplicate of this bug. ***
Comment 4 rubydoo123 2000-08-30 15:44:44 PDT
*** Bug 50263 has been marked as a duplicate of this bug. ***
Comment 5 Nisheeth Ranjan 2000-08-30 16:41:20 PDT
Marking nsbeta3-.  Workaround is to use the context menu to bring up the 
properties dialog, right?
Comment 6 saari (gone) 2000-08-30 17:33:51 PDT
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 2000-08-30 18:51:55 PDT
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 2000-08-31 07:36:30 PDT
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 2000-08-31 13:10:59 PDT
*** Bug 50578 has been marked as a duplicate of this bug. ***
Comment 10 Charles Manske 2000-09-01 13:28:40 PDT
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 2000-09-05 17:02:11 PDT
The workaround for Composer is checked in.
Comment 12 Nisheeth Ranjan 2000-09-11 14:33:44 PDT
In light of Charley's workaround for the editor, minusing and futuring.
Comment 13 rubydoo123 2000-09-19 16:18:06 PDT
*** Bug 53257 has been marked as a duplicate of this bug. ***
Comment 14 Loco 2000-09-25 12:39:05 PDT
Updating QA Contact.
Comment 15 Gervase Markham [:gerv] 2000-10-24 16:05:59 PDT
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 2001-01-19 06:59:34 PST
Changing Status for my reference.  Was NSBETA3-.  Anyone think this 
should be renominated?
Comment 17 Charles Manske 2001-01-19 11:12:24 PST
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) 2001-01-29 10:20:58 PST
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 2001-06-15 15:10:37 PDT
QA contact updated
Comment 20 rubydoo123 2002-03-08 11:59:31 PST
removing myself from the cc list
Comment 21 Simon Fraser 2002-03-11 17:33:08 PST
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 2002-03-13 12:38:01 PST
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) 2002-10-30 10:58:12 PST
topembed+, a general issue we should try to get fixed
Comment 24 Brian Ryner (not reading) 2002-12-12 18:17:52 PST
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) 2003-01-10 11:14:46 PST
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 2003-03-17 16:00:57 PST
Discussed in edt.  Minusing.
Comment 27 Wayne Mery (:wsmwk, NI for questions) 2009-04-29 14:41:49 PDT
WFM 
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.15) Gecko/20080615 SeaMonkey/1.1.10

Note You need to log in before you can comment on or make changes to this bug.