212753 - Select boxes changing settings without user input - strange behaviour with a dynamic HTML page.

Status: RESOLVED FIXED

(SeaMonkey :: General, defect, P2)

Description

[William Noad]

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.

Comment 1

[William Noad]

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

Comment 2

[Boris Zbarsky [:bzbarsky]]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[William Noad]

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.

Comment 5

[William Noad]

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?

Comment 6

[chris hofmann]

we should try and knock off this regression be for 1.5 beta.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Probably related to bug 207637

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

My patch for 207637 doesn't fix this. :-(

Comment 9

[Christopher Aillon (sabbatical, not receiving bugmail)]

This is a bad regression since it mangles user selected form data.  Any progress
here, roc?

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: 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.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: revised patch

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

Comment 13

[Hermann Schwab]

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

Comment 14

[Mike Kaply [:mkaply]]

Comment on attachment 130698 [details] [diff] [review]
revised patch

a=mkaply

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Fix checked in.

Comment 16

[William Noad]

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