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

RESOLVED FIXED

Status

SeaMonkey
General
P2
major
RESOLVED FIXED
15 years ago
14 years ago

People

(Reporter: William Noad, Assigned: roc)

Tracking

({regression})

Trunk
x86
Linux
regression
Bug Flags:
blocking1.5b +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

15 years ago
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.
(Reporter)

Comment 1

15 years ago
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.
Assignee: general → roc+moz
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Priority: -- → P2
(Reporter)

Comment 4

15 years ago
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.
(Reporter)

Comment 5

15 years ago
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?
Flags: blocking1.5b?

Comment 6

15 years ago
we should try and knock off this regression be for 1.5 beta.
Flags: blocking1.5b? → blocking1.5b+
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
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
Attachment #130698 - Flags: superreview?(bryner)
Attachment #130698 - Flags: review?(bryner)
Attachment #130698 - Flags: superreview?(bryner)
Attachment #130698 - Flags: superreview+
Attachment #130698 - Flags: review?(bryner)
Attachment #130698 - Flags: review+

Comment 13

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

Comment 14

15 years ago
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
(Reporter)

Comment 16

15 years ago
Thanks for the effort guys.  It works perfectly now. :-)
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.