Closed
Bug 879838
Opened 12 years ago
Closed 12 years ago
double-click in html compose opens list or table properties dialog
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla25
People
(Reporter: bughunter2, Assigned: neil)
Details
Attachments
(1 file, 1 obsolete file)
3.52 KB,
patch
|
smaug
:
review+
|
Details | Diff | Splinter Review |
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.)
Assignee | ||
Comment 2•12 years ago
|
||
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.
Updated•12 years ago
|
Keywords: regressionwindow-wanted
Assignee | ||
Comment 3•12 years ago
|
||
Slightly smaller regression window: Gecko 4 works, Gecko 19 does not.
Assignee | ||
Comment 4•12 years ago
|
||
Huh, my old Gecko 19 local alpha fails, but a Gecko 19 download passes...
Assignee | ||
Comment 5•12 years ago
|
||
OK, so Gecko 20 passes and Gecko 22 fails.
Assignee | ||
Comment 6•12 years ago
|
||
Changeset 2e91ff229d84 has the bug but changeset c90d44bfa96c does not. Still 5647 changesets though...
Assignee | ||
Comment 7•12 years ago
|
||
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.
Assignee | ||
Comment 8•12 years ago
|
||
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).
Assignee | ||
Comment 9•12 years ago
|
||
Switching to mozilla-central I now have a new range of 38407b98003b to 66d595814554 (499 changesets). hg bisect says that it's changeset ee0e5b1c1640.
Blocks: 824823
Component: Untriaged → DOM
Keywords: regressionwindow-wanted → regression
Product: Thunderbird → Core
Version: 22 → 20 Branch
Assignee | ||
Comment 10•12 years ago
|
||
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).
Assignee | ||
Comment 11•12 years ago
|
||
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...
Assignee | ||
Comment 12•12 years ago
|
||
And the regression window for the second bug is somewhere between 0a6e5a67c4e8 and 677e87c11252 (2057 changesets).
Assignee | ||
Comment 13•12 years ago
|
||
I've found some intermediate builds, so that brings the second bug range down to 19f630648c80 to 47684913d63d (165 changesets).
Assignee | ||
Comment 14•12 years ago
|
||
But unfortunately hg bisect blames a merge changeset 47684913d63d...
Assignee | ||
Comment 15•12 years ago
|
||
...yet neither parent of that changeset demonstrates the second bug...
Assignee | ||
Comment 16•12 years ago
|
||
So, a downloaded build from that changeset fails, but my self-build of the same changeset works locally...
Comment 17•12 years ago
|
||
> 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.
Assignee | ||
Comment 18•12 years ago
|
||
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...
Assignee | ||
Comment 19•12 years ago
|
||
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 | ||
Updated•12 years ago
|
No longer blocks: 824823
Keywords: regression
OS: Windows 7 → All
Hardware: x86_64 → All
Version: 20 Branch → Trunk
Assignee | ||
Comment 20•12 years ago
|
||
Comment 21•12 years ago
|
||
Comment on attachment 776029 [details] [diff] [review]
Proposed patch
r+ but this needs tests before landing.
Attachment #776029 -
Flags: review?(bugs) → review+
Assignee | ||
Comment 22•12 years ago
|
||
Attachment #776029 -
Attachment is obsolete: true
Attachment #776471 -
Flags: review?(bugs)
Updated•12 years ago
|
Attachment #776471 -
Flags: review?(bugs) → review+
Assignee | ||
Comment 23•12 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•