Closed Bug 879838 Opened 7 years ago Closed 7 years ago
double-click in html compose opens list or table properties dialog
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release) Build ID: 20130528181031 Steps to reproduce: In a html or rich-text compose window, I double click on a word that is part of a list or a table. Actual results: In addition to the text being highlighted, the List or Table Properties dialog pops up. This does not happen in a simple paragraph text Expected results: The properties editor dialog boxes should not pop up. It's absolutely infuriating to have to hit escape after every double-click. There are other reports of similar problems in the fora but most mention double-clicking on white-space. This happens when I am highlighting text and the mouse is directly over text when I double-click. Some have suggested that it is due to a defective mouse. However, this happens with different mice including a brand new one. All mice are of the typical 3-button scroll wheel variety and none exhibit any abnormal behaviour with other applications. I am using Windows 7 typically and the problem does not happen on Linux although I am using an older version on that platform. This also happens in "Safe Mode" so I cannot blame Addons or Extensions.
Confirmed - in SeaMonkey 2.19 (akin to FF/TB 22), SeaMonkey Composer (& I would suspect Mail too?). Opening this bug in Composer should provide a sufficient test case. SeaMonkey 2.17 (akin to FF/TB 20) looks to work as expected. (There was not SeaMonkey 2.18.)
What's happens here is that the double-click handler checks the event's explicitOriginalTarget, which is supposed to be the text node. And indeed in Gecko 1.9 it is. (Sorry I don't have a later version of Gecko handy.) But in Gecko 25 is isn't. In particular, in Gecko 1.9 the target frame is a text frame, but in Gecko 25 it's a block frame.
Slightly smaller regression window: Gecko 4 works, Gecko 19 does not.
Huh, my old Gecko 19 local alpha fails, but a Gecko 19 download passes...
OK, so Gecko 20 passes and Gecko 22 fails.
Changeset 2e91ff229d84 has the bug but changeset c90d44bfa96c does not. Still 5647 changesets though...
Changeset d18a62362aab is the earliest bad changeset I can find. Still 5377 changesets though. I can't bisect any further because there aren't any other Windows SeaMonkey builds, and I can't easily use other platforms, and Thunderbird and Firefox builds would be a lot harder to test, and I can't seem to find a matching pair of c-r and m-r changesets to build locally with.
I managed to find some earlier Windows builds (I forgot they were kept in another folder) and I'm now back as far as 0a6e5a67c4e8 being a bad changeset (1103 left).
Switching to mozilla-central I now have a new range of 38407b98003b to 66d595814554 (499 changesets). hg bisect says that it's changeset ee0e5b1c1640.
And the big difference before and after that changeset is that document.createTextNode("").QueryInterface(Components.interfaces.nsIDOMElement) no longer throws (instanceof still fails of course).
Just to be confusing, there's actually a second bug sometime between then and now whereby the explicitOriginalTarget isn't a text node any more, so I'm going to have to bisect all over again to track that one down...
And the regression window for the second bug is somewhere between 0a6e5a67c4e8 and 677e87c11252 (2057 changesets).
I've found some intermediate builds, so that brings the second bug range down to 19f630648c80 to 47684913d63d (165 changesets).
But unfortunately hg bisect blames a merge changeset 47684913d63d...
...yet neither parent of that changeset demonstrates the second bug...
So, a downloaded build from that changeset fails, but my self-build of the same changeset works locally...
> createTextNode("").QueryInterface(Components.interfaces.nsIDOMElement) no longer throws That would have been the cause until bug 827546 was fixed, but in Firefox 21 and anything after that that expression should throw.
OK, so the second bug was exposed by a c-c change, not an m-c change. In bug 827017 I switched from a click handler to a dblclick handler. Unfortunately the dblclick event's explicitOriginalTarget is not the same as the click event's explicitOriginalTarget...
And that's due to a bug in code that dates back to CVS; when we dispatch the click event we accidentally forget the target so we end up dispatching the double click event to a different target.
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #776029 - Flags: review?(bugs)
Comment on attachment 776029 [details] [diff] [review] Proposed patch r+ but this needs tests before landing.
Attachment #776029 - Flags: review?(bugs) → review+
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
You need to log in before you can comment on or make changes to this bug.