User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 As part of a development project I'm working on I have created a dynamic HTML page . The HTML sent to the browser is created through a CGI script written in Perl using the Template Toolkit. The JavaScript element is used to get the user to enter the data correctly so that I get back the cmtsNumber. The user selects a CMTS by first selecting the Franchise, then a DHCP within that Franchise. The JavaScript updateForm() function is used to manage the three select boxes. When a Franchise is selected the DHCP select box is populated with appropriate entries from the static data table stored in the page. When a DHCP is selected the CMTS select box is populated with appropriate CMTS entries. This form works under Mozilla 1.3.1/1.2, Konqueror 3.x and MS Internet Explorer 5.x/6.x. Under Mozilla 1.4 the Franchise selector is reset (apparently at random) when the DHCP selector is clicked (not changed). Although the selector changes, a debugging alert statement placed in the code did not show a call to the updateForm() function. Similar problems occur with the CMTS select box. Reproducible: Always Steps to Reproduce: 1. Select 'Surrey & Hants' from the Franchise select box. 2. Click on the drop-down button of the DHCP select box. 3. The Franchise select box changes to 'Cablelink'. 4. On the second click the drop down for Franchise 'Cablelink' appears. Actual Results: The form becomes unusable within Mozilla 1.4. Expected Results: What I expected was that the DHCP select box would have the 'Surrey & Hants' DHCPs (Guildford, Test Lab) listed. I have not been able to test this on any other platforms. This is a serious problem for me as it means that my development platform is broken so long as I keep using Mozilla 1.4.

Just tested it on Windows 2K w/ Mozilla 1.4 - same results.

Does using just the function name in the event handler help? That is, instead of: onchange="javascript:foo()" do onchange="foo()" ? I'm definitely seeing the changed behavior in a current nightly; tracking down regression window now.

This regressed between 2003-04-08-05 and 2003-04-09-05; pride of place goes to roc, since he whacked comboboxes then.

I have just tested changing the onChange="javascript:updateForm()" to onChange="updateForm()" but it doesn't make any differenece. The select boxes are still behaving erractically.

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.

Probably related to bug 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?

I tracked this down, sort of. The basic problem is that when you select something from the first popup and the popup is dismissed, it keeps the mouse capture! Thus when you try to click to activate the second popup, your click is directed to the (hidden) popup for the first combobox, and you may end up selecting something else there. Try it and see what I mean. This is caused by this sequence of events: -- User actives the popup for the first combobox -- At this time the popup sets the mouse capture to the view for the popup -- User clicks on some option in the popup -- During button press event, the actual option frame calls nsFrame::HandlePress which sets mouse event capturing to the frame's view (the scrolled block containing the options) -- During button release event, nsListControlFrame::MouseUp responds by hiding the popup. It tries to release the mouse capture but decides not to because in fact the list box itself is not capturing the mouse (any more) -- nsListControlFrame::MouseUp does call stuff that eventually calls FireOnChanged. The onchange Javascript handler destroys all the options and rebuilds them. *the option frame that originated the mouse capture is destroyed* so nsFrame::HandleRelease is not called (I think that the event state manager learns that the original event target has been destroyed and stops delivering the event ... I should investigate this more) -- Event processing is done; the popup is hidden but mouse events are still being captured by the scrolled block inside the popup

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.

Missed a file ... here's the real thing

*** Bug 217804 has been marked as a duplicate of this bug. ***

Comment on attachment 130698 [details] [diff] [review] revised patch a=mkaply

Fix checked in.

Thanks for the effort guys. It works perfectly now. :-)