Closed
Bug 3322
Opened 26 years ago
Closed 25 years ago
[PP][BLOCK]ender/wallet -- select ONCHANGE handler failures
Categories
(Core :: Layout: Form Controls, defect, P2)
Tracking
()
VERIFIED
FIXED
M15
People
(Reporter: morse, Assigned: kmcclusk)
References
()
Details
(Whiteboard: Windows broken. Linux and Mac fixed.)
The content below displays a drop-down list with two elements. The onchange
handler is supposed to be called whenever the selected element changes. Instead
it is being called whenever the list is dropped down.
Let me be more specific. Perform the following sequence of steps:
1. Move mouse cursor to the list and click the left mouse button. The list
drops down. Without changing the current selection, release the left mouse
button. In seamonkey, the alert message is triggered. In 4.5 the alert message
is not triggered at this time.
2. Move mouse cursor to the list and click the left mouse button. This list
drops down. With the button remaining pressed, change the current selection.
Now release the left mouse button. In seamonkey, the alert message is not
triggered. In 4.5 the alert message is triggerd at this time.
The behavior in 4.5 is the correct one -- the seamonkey behavior is incorrect.
Note: This was originally reported as a side comment in bug 3286. But that bug
had to do with a crash which is a totally separate issue. So this has been
broken out of that report and reported here as a bug in its own right.
<HTML>
<HEAD>
<SCRIPT>
function changed() {
alert("Change occurred");
}
function loadMain() {
top.frames[0].document.open();
top.frames[0].document.write(
"<FORM>" +
"<TABLE>" +
"<TR>" +
"<TD>" +
"<SELECT ONCHANGE=top.changed();>" +
"<OPTION> abc </OPTION>" +
"<OPTION> def </OPTION>" +
"</SELECT>" +
"</TD>" +
"</TR>" +
"</TABLE>" +
"</FORM>"
);
top.frames[0].document.close();
}
</SCRIPT>
</HEAD>
<FRAMESET ROWS=*,1
BORDER=0
FRAMESPACING=0
onLoad=loadMain()>
<FRAME SRC=about:blank
NAME=main_frame
SCROLLING=AUTO
MARGINWIDTH=0
MARGINHEIGHT=0
NORESIZE>
<FRAME SRC=about:blank
NAME=dummy_frame
SCROLLING=AUTO
MARGINWIDTH=0
MARGINHEIGHT=0
NORESIZE>
</FRAMESET>
<NOFRAMES>
<BODY> <P> </BODY>
</NOFRAMES>
</HTML>
Updated•26 years ago
|
Assignee: norris → vidur
Comment 1•26 years ago
|
||
Sounds like a DOM thing.
Updated•26 years ago
|
Assignee: vidur → pollmann
Updated•26 years ago
|
Status: NEW → ASSIGNED
Comment 2•26 years ago
|
||
The ONCHANGE handler is also not being called at all on Linux.
Looking into both issues.
Updated•26 years ago
|
Summary: javascript ONCHANGE handler not being called at right time → javascript ONCHANGE handler failures
Comment 3•26 years ago
|
||
Partial fix:
The onchange handler is no longer called every time the combo box is clicked on,
only when clicked on after a change.
Still needed:
Change notifications on Linux.
Should not need to click on widget after change to get notification.
Comment 4•26 years ago
|
||
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
QA contact re-assigned according to the product areas we're currently working
on.
Comment 7•26 years ago
|
||
Tom, do you have any idea how to get the mouseUp notifications into the dom when
a user clicks on an entry in the drop-down list of a combo box? I've been
stumped by this one. The mouseUp event doesn't appear to be entering the the
event system at all until the mouse leaves the window.
Reporter | ||
Updated•26 years ago
|
Target Milestone: M3
Reporter | ||
Updated•26 years ago
|
Summary: javascript ONCHANGE handler failures → [BLOCK]wallet -- javascript ONCHANGE handler failures
Updated•26 years ago
|
Component: JavaScript → Widget Set
Comment 8•26 years ago
|
||
CC'ing Rod. Rod, can you look this one over?
We need to get notifications of combo box selection changes into the
nsSelectControlFrame code. The way this is being done now is checking selected
options after each MouseUp event and comparing with the previous list to see if
the selection has changed. (see nsSelectControlFrame::MouseClicked())
The problem is that MouseUp events in the drop-down window are not entering the
event system (nsWindow doesn't even get them).
Is there a way to get the mouse events from the drop-down window? Would it be
better to do this check on ON_CMB_SELCHANGE notifications for windows and a
similar, platform specific notification for gtk and mac? Is there another clean
way to get this notification into the event system?
Comment 10•26 years ago
|
||
*** Bug 4273 has been marked as a duplicate of this bug. ***
Updated•26 years ago
|
OS: Windows NT → All
Comment 11•26 years ago
|
||
*** Bug 4410 has been marked as a duplicate of this bug. ***
Comment 12•26 years ago
|
||
onChange also doesn't work on Mac.
Comment 13•26 years ago
|
||
This bug is on M3 milestone which has passed. Putting on Blank milestone to be
reassigned to a current or future milestone.
Updated•26 years ago
|
Target Milestone: M5
Comment 14•26 years ago
|
||
*** Bug 3021 has been marked as a duplicate of this bug. ***
Comment 15•26 years ago
|
||
*** Bug 3018 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Target Milestone: M5 → M6
Comment 16•25 years ago
|
||
*** Bug 4061 has been marked as a duplicate of this bug. ***
Comment 17•25 years ago
|
||
*** Bug 5945 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Severity: normal → blocker
Comment 18•25 years ago
|
||
This is a blocker for Editor group as well
Comment 19•25 years ago
|
||
Adding myself to CC. We need this ASAP!
Comment 20•25 years ago
|
||
This weekend I tried another approach - in keeping with the spec, ONCHANGE's
should only come when the widget looses focus (this is contrary to the way it is
implemented in both IE 5.0 AND Nav 4.5). Problem with that approach is,
mouseExit events are also not entering the event system for combo boxes (as with
the current implementation, it works fine with listboxes). :S
The ONCHANGE notification is completely dependent on the widget being
implemented correctly, and native combo box widgets are missing the ability to
send many event notification types (it seems). I'm going to try my hand at
fixing the windows and gtk widgets, but I can't work on Mac because I don't have
a machine...
Updated•25 years ago
|
Summary: [BLOCK]wallet -- javascript ONCHANGE handler failures → [BLOCK]ender/wallet -- javascript ONCHANGE handler failures
Comment 21•25 years ago
|
||
Whe you say "loose focus", do you really mean just the drop-down list portion?
On Windows, such as MFC's CComboBox, that's how it works. In other words, after
clicking and changing selection, the list closes, the OnChange message fires,
but the closed widget (editbox+down arrow button) technically still has the
focus.
Updated•25 years ago
|
Target Milestone: M6 → M7
Comment 22•25 years ago
|
||
Yes, this is how it will (should) function.
Unfortunately, it is not easy to hook this up with the current event system. No
events are reliably sent through nsWindow::ProcessMessage when the closeup
happens.
The only solution I can come up with (not being a Windows GUI guru) is to
register a CComboBox onCloseUp callback to get this notification. We don't
register for GUI callbacks like this anywhere I can find, so the infrastructure
to do this isn't in place. And I since I'm not intimately familiar with the
event system, I don't know what it should look like. Who should register for
the callback? How will the selectControlFrame be notified?
Not going to get this in for M6, depsite my overwhelming desire to make it so.
Anyone got ideas for this one? XP ideas? Help?
Rolling over to M7...
Comment 23•25 years ago
|
||
From bug 5944: No mouse events in the dropdown list of a combo box enter the
event system. This is closely related to this bug.
Comment 24•25 years ago
|
||
*** Bug 5937 has been marked as a duplicate of this bug. ***
Comment 25•25 years ago
|
||
Thanks to a tip from cmanske this morning and a little hacking of nsWindow.cpp,
I've got viewer printing out "Hello world." on CBN_SELENDOK messages. It's a
step on the road to a solution (for Windows) anyway. Thanks Charlie!
Comment 26•25 years ago
|
||
Just checked in a fix for Linux.
Comment 27•25 years ago
|
||
Just checked in a fix for Windows. I'm sending out onChanges for
CBN_SELENDCANCEL as well as CBN_SELENDOK as that is what IE does and it makes a
good deal of sense.
There was a targeting issue as this event is sent out to the parent window but I
used a workaround similar to what is done for the TABCHANGE event.
Updated•25 years ago
|
Assignee: pollmann → pierre
Status: ASSIGNED → NEW
OS: All → Mac System 8.0
Hardware: PC → Macintosh
Summary: [BLOCK]ender/wallet -- javascript ONCHANGE handler failures → [PP][BLOCK]ender/wallet -- javascript ONCHANGE handler failures
Comment 28•25 years ago
|
||
Pierre, can you update the Mac nsComboBox.cpp (if Mac is more like GTK) or
nsWindow.cpp (if Mac is more like Windows) so that an NS_CONTROL_CHANGE event is
sent when the selected item in a combo box is changed?
I attempted to mimic IE's behavior in the sending of this event as closely as
possible:
- On both Windows and GTK, this event is sent when the drop-down list closes (on
a mouse click, or an Enter or Escape key press).
- On Windows, it is also sent when the arrow keys are used to change the
selected item if the list is not dropped down. (arrow keys can't be used to
select an item on GTK)
- On neither platform is the event sent out every time a new option is
highlighted when the dropdown list is open. This is what Nav 4.5 did and was an
accessibility complaint (prohibited keyboard-only selection of an option).
Comment 29•25 years ago
|
||
*** Bug 6458 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 30•25 years ago
|
||
*** Bug 2964 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Assignee: pierre → pollmann
Status: ASSIGNED → NEW
Comment 31•25 years ago
|
||
I fixed the Mac to send NS_CONTROL_CHANGE events. I also checked that layout/
html/forms/src/nsFormControlFrame::HandleEvent() was called.
However, the test at the URL above still doesn't work but that's a cross-platform
problem (I checked with today's build on Win32). Reassigning back to <pollmann>
to take care of it.
Comment 32•25 years ago
|
||
I also checked on http://marvin.mcom.com/whitebox/tools/Event%20Tools/16-1.html
that the list box and the popup menu are working correctly: the Change events are
reported in the text field.
Comment 33•25 years ago
|
||
cc'ing myself
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 34•25 years ago
|
||
Thanks Pierre, great work!
Updated•25 years ago
|
OS: Mac System 8.0 → Windows 98
Hardware: Macintosh → PC
Comment 35•25 years ago
|
||
This is broken again now on Windows (Finally, both Mac and Linux are ahead of
Windows on a feature!). I made the mistake of not testing my changes on 98 or
95, which Kevin was kind enough to fix. From his post to n.p.m.layout.checkins:
"...Even though the MS documentation claims you should use the lParam, it does
*not* work. This is what was causing the crashes on WIN95 and WIN98. The
window handle was bogus so it was trying to get user data from invalid window
handle. Later, code tried to dispatch an event using this invalid window
pointer"
The existing problem is that the CBN_SELENDOK and CBN_SELENDCANCEL notifications
are sent to the combo's parent window, not the combo window itself. This is
similar to the way a tab control's change event is handled. Without knowing the
window itself, the event code can't find the event's offset, and thus can't send
the event to the proper frame. It falls off the face of the earth and the frame
model gets out of sync with the widget.
The code I had changed to work around this was nsWindow::WindowProc. On NT
lParam contains the combo window that originated the event. But this is not the
case for 95 or 98, and, um, bad things happen (bluescreen). Do we have a
Window's guru who knows how to get the combo window for this event on NT, 98,
*and* 95?
Comment 36•25 years ago
|
||
This remaining problem should go away when GFX widgets become the default.
Postponing this one until "much later"
Updated•25 years ago
|
Target Milestone: M7 → M12
Comment 37•25 years ago
|
||
*** Bug 8284 has been marked as a duplicate of this bug. ***
Comment 38•25 years ago
|
||
I hear the GFX widgets will get turned on M8. If so, why is this moved to M12 ?
Comment 39•25 years ago
|
||
In my case, it's been a way to triage bugs. I marked M15 all the bugs that were
dependent on Ender or GFX widgets because I did not want to just close them as
Later or WontFix.
Updated•25 years ago
|
Target Milestone: M12 → M15
Comment 40•25 years ago
|
||
*** Bug 8363 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
QA Contact: janc → phillip
Comment 41•25 years ago
|
||
Not sure how I ended up with a widget bug, reassigning QA Contact to Phillip.
Comment 42•25 years ago
|
||
Moving all Widget Set bugs, past and present, to new HTML Form Controls
component per request from karnaze. Widget Set component will be retired
shortly.
Comment 43•25 years ago
|
||
Using the June 21/22 M8 builds, I see the onChange handler working on linux and
Mac OS, but failing on Win32. (I had wanted to file a bug report against that
but figured this was the right place to insert comments.) Is this expected
behavior? My test case is at http://schist/delta.html/.
Updated•25 years ago
|
Whiteboard: Windows broken. Linux and Mac fixed.
Comment 44•25 years ago
|
||
Indeed this is the right place. Unfortunately, yes, Windows is still broken.
I've updated the Status Whiteboard to reflect this.
Updated•25 years ago
|
Summary: [PP][BLOCK]ender/wallet -- javascript ONCHANGE handler failures → [PP][BLOCK]ender/wallet -- select ONCHANGE handler failures
Comment 45•25 years ago
|
||
Removing my name from CC.
Comment 46•25 years ago
|
||
*** Bug 11840 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•25 years ago
|
Assignee: pollmann → rods
Status: ASSIGNED → NEW
Assignee | ||
Comment 47•25 years ago
|
||
This example http://blueviper/forms/onchange3.html is not working with gfx
rendered selects. I set a break point
in nsComboboxControlFrame::SelectionChanged() and it is being called and the
event is dispatched to the DOM. After that, nothing happens. This use to work.
Rod could you take a look.
Assignee | ||
Updated•25 years ago
|
Assignee: rods → kmcclusk
Assignee | ||
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 48•25 years ago
|
||
The test case http://blueviper/forms/onchange3.html works with gfx-rendered
select. It does not work inside viewer because the javascript alert function
does nothing when running inside viewer. If the dump function is used instead of
alert then the message is printed when the selection changes in viewer.
gfx-rendered widgets are enabled as the default as of Aug 19, 1999, 4:00PM.
Comment 49•25 years ago
|
||
verified fixed on
1999-09-13-08-M10 RedHat Linux 6.0 (GNOME/enlightenment)
1999-09-13-08-M10 WinNT 4.0 sp5
1999-09-13-08-M10 MacOS 8.51
You need to log in
before you can comment on or make changes to this bug.
Description
•