Just tested it on Windows 2K w/ Mozilla 1.4 - same results.
This regressed between 2003-04-08-05 and 2003-04-09-05; pride of place goes to roc, since he whacked comboboxes then.
Assignee: general → roc+moz
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
THis is still a problem in Mozilla 1.5a (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030718) Can this be marked as a blocker on the release of 1.5?
we should try and knock off this regression be for 1.5 beta.
Flags: blocking1.5b? → blocking1.5b+
Probably related to bug 207637
15 years ago
Depends on: 207637
My patch for 207637 doesn't fix this. :-(
This is a bad regression since it mangles user selected form data. Any progress here, roc?
Created attachment 130672 [details] [diff] [review] fix Here's a fix. The fix is actually all in nsListControlFrame.cpp. nsMenuPopupFrame.h is just removal of an unused field I found while researching this bug. nsComboboxControlFrame.cpp is a simple related bug I found while inspecting the code: if we're hiding the popup list, then we should be *disabling* capture of rollup events, not enabling them. The fix for this bug is straightforward: whenever CaptureMouseEvents is called, we check to see whether the popup (aka dropdown) is hidden; if it is, remove any capturer even if we weren't the one who set it. Because the combobox rollup code always calls nsListControlFrame::CaptureMouseEvents when the popup is hidden, this bit of defensive coding will always ensure that no-one is still capturing. Probably one could construct a pure DOM testcase where content is deleted on mouseup and nsFrame::HandleRelease is therefore not called, and mouse capturing is therefore inappropriately retained. Fixing that may require a somewhat deeper reworking of mouse capturing. The patch also removes nsListControlFrame::mIsCapturingMouseEvents, because this isn't currently used.
Created attachment 130698 [details] [diff] [review] revised patch Missed a file ... here's the real thing
Attachment #130672 - Attachment is obsolete: true
*** Bug 217804 has been marked as a duplicate of this bug. ***
Attachment #130698 - Flags: approval1.5?
Comment on attachment 130698 [details] [diff] [review] revised patch a=mkaply
Attachment #130698 - Flags: approval1.5? → approval1.5+
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Thanks for the effort guys. It works perfectly now. :-)
You need to log in before you can comment on or make changes to this bug.