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
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
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!
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.
*** Bug 50607 has been marked as a duplicate of this bug. ***
*** Bug 50263 has been marked as a duplicate of this bug. ***
Marking nsbeta3-. Workaround is to use the context menu to bring up the
properties dialog, right?
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.
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!
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
*** Bug 50578 has been marked as a duplicate of this bug. ***
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)
The workaround for Composer is checked in.
In light of Charley's workaround for the editor, minusing and futuring.
*** Bug 53257 has been marked as a duplicate of this bug. ***
Updating QA Contact.
Now that the workaround's in, does this need a relnote of some sort?
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.
Changing Status for my reference. Was NSBETA3-. Anyone think this
should be renominated?
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 updated
removing myself from the cc list
What's up with this bug? We need to fix it to be able to clean up the editor
APIs for embedding.
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.
topembed+, a general issue we should try to get fixed
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.
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
Discussed in edt. Minusing.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:184.108.40.206) Gecko/20080615 SeaMonkey/1.1.10