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.
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! Please reconsider.
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.
*** 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? 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
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.
WFM Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:184.108.40.206) Gecko/20080615 SeaMonkey/1.1.10