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)

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: morse, Assigned: kmcclusk)

References

(
URL
)

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>
Assignee: norris → vidur
Sounds like a DOM thing.
Assignee: vidur → pollmann
URL: http://blueviper/forms/onchange3.html
Status: NEW → ASSIGNED
The ONCHANGE handler is also not being called at all on Linux. Looking into both issues.
Summary: javascript ONCHANGE handler not being called at right time → javascript ONCHANGE handler failures
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.
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
DOM bugs are not my problem.
QA Contact: 4015 → 3847
QA contact re-assigned according to the product areas we're currently working on.
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.
Target Milestone: M3
Summary: javascript ONCHANGE handler failures → [BLOCK]wallet -- javascript ONCHANGE handler failures
Component: JavaScript → Widget Set
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?
*** Bug 4014 has been marked as a duplicate of this bug. ***
*** Bug 4273 has been marked as a duplicate of this bug. ***
OS: Windows NT → All
*** Bug 4410 has been marked as a duplicate of this bug. ***
onChange also doesn't work on Mac.
This bug is on M3 milestone which has passed. Putting on Blank milestone to be reassigned to a current or future milestone.
Target Milestone: M5
*** Bug 3021 has been marked as a duplicate of this bug. ***
*** Bug 3018 has been marked as a duplicate of this bug. ***
Target Milestone: M5 → M6
*** Bug 4061 has been marked as a duplicate of this bug. ***
*** Bug 5945 has been marked as a duplicate of this bug. ***
Severity: normal → blocker
This is a blocker for Editor group as well
Adding myself to CC. We need this ASAP!
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...
Summary: [BLOCK]wallet -- javascript ONCHANGE handler failures → [BLOCK]ender/wallet -- javascript ONCHANGE handler failures
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.
Target Milestone: M6 → M7
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...
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.
*** Bug 5937 has been marked as a duplicate of this bug. ***
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!
Just checked in a fix for Linux.
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.
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
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).
*** Bug 6458 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Blocks: 7530
*** Bug 2964 has been marked as a duplicate of this bug. ***
Assignee: pierre → pollmann
Status: ASSIGNED → NEW
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.
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.
cc'ing myself
Status: NEW → ASSIGNED
Thanks Pierre, great work!
OS: Mac System 8.0 → Windows 98
Hardware: Macintosh → PC
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?
This remaining problem should go away when GFX widgets become the default. Postponing this one until "much later"
Target Milestone: M7 → M12
*** Bug 8284 has been marked as a duplicate of this bug. ***
I hear the GFX widgets will get turned on M8. If so, why is this moved to M12 ?
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.
Target Milestone: M12 → M15
*** Bug 8363 has been marked as a duplicate of this bug. ***
QA Contact: janc → phillip
Not sure how I ended up with a widget bug, reassigning QA Contact to Phillip.
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.
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/.
Whiteboard: Windows broken. Linux and Mac fixed.
Indeed this is the right place. Unfortunately, yes, Windows is still broken. I've updated the Status Whiteboard to reflect this.
Blocks: 8949
Summary: [PP][BLOCK]ender/wallet -- javascript ONCHANGE handler failures → [PP][BLOCK]ender/wallet -- select ONCHANGE handler failures
Removing my name from CC.
*** Bug 11840 has been marked as a duplicate of this bug. ***
Assignee: pollmann → rods
Status: ASSIGNED → NEW
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: rods → kmcclusk
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
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.