Closed Bug 7595 Opened 25 years ago Closed 25 years ago

onchange function never gets called for GFX text control

Categories

(Core :: Layout: Form Controls, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: Brade, Assigned: pollmann)

References

Details

(Whiteboard: [19990909] requesting info from hangas regarding addressbook issues)

Attachments

(3 files)

When changing any of the values for any of the html form controls, the onchange
function doesn't get called.  See attachment.
QA Contact: cbegle → gerardok
Kathy: OnChange now works for the HTML <select> tag, but it doesn't work for
the input type="text" control. I'm not sure about others, but it would be
good to find out exactly which form controls don't work and file individual
bugs to appropriate people. (I don't think joki is the right target for
any of these.) Please specify which control in the Summary field
to assist searching for bugs.
Assignee: joki → pollmann
Sending this to pollmann.  He knows more about onchange than me these days.
Component: JavaScript → DOM Level 0
Moving to DOM Level 0 component.  Move to DOM Level 1 if that is more correct.
Status: NEW → ASSIGNED
QA Contact: gerardok → janc
Target Milestone: M9
We really need these to all work for M9.
Eric--can you fix this by then?
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Hi Kathy!

The main issue I can think of here is the switch to GFX widgets as the default.
As such, enabling onChange for native widgets, I'm told, has a much lower
priority.  Do you need onChange enabled for native widgets or would enabling it
for GFX widgets be sufficient (or do you need both?)

From the example here, it seems, the controls in question are:

<SELECT>              Works only on GTK and Mac (GFX and Win not reported)
<INPUT TYPE=RADIO>    Not reported
<INPUT TYPE=CHECKBOX> Not reported
<INPUT TYPE=TEXT>     Not reported
<INPUT TYPE=PASSWORD> Not reported
<INPUT TYPE=FILE>     Not reported
<TEXTAREA>            Not reported

onChange does not work for any GFX rendered widgets, including the select widget
and the ender-based text widget.

Getting radios and checkboxes to report onChange events should be very doable by
M9, for either GFX or native or both.  Text inputs, passwords, text areas, and
file inputs are harder and may not be doable by M9.  Select widgets working on
GFX is probably doable, but Windows is very unlikely for M9 or even beyond. (See
bug 3322)

I guess what I need to know is, given all that, what are you highest priorities
to get working by M9?
Component: DOM Level 0 → HTML Form Controls
IMHO, get the GFX widgets done and turned on as the default so we can
concentrate filing bugs and fixing what we are supposed to ship with!
If we are supposed to always use GFX, I don't care about native widgets.
Given that, supporting OnChange for the text widgets (both "input" and
"textarea") and Select are the most important.
I'm cc'ing Kevin (GFX select guru) and Steve (GFX text guru) on this bug.  The
widgets themselves need to send out a NS_CONTROL_CHANGE event when there is a
change.  This can then be intercepted by the form frame code (already will be
for the select) and converted into a DOM onChange event.
I don't have the first clue about OnChange notifications, who is responsible for
firing them, what the mechanism is for a control to fire an event, etc.  Point
me in the right direction:  some documentation, a set of requirements, a working
example, etc, and I'll get it in right away for text fields, password fields,
and text areas.  What other notifications do I need to know about, and how
important are they?  Thanks.
An example of working onChange events is the combo box on GTK:

The event is generated by the widget when the combo box is closed up:
nsComboBox::OnUnmapSignal() (widget/src/gtk/nsComboBox.cpp, line 344)

  // Generate a NS_CONTROL_CHANGE event and send it to the frame
  nsGUIEvent event;
  event.eventStructType = NS_GUI_EVENT;
  nsPoint point(0,0);
  InitEvent(event, NS_CONTROL_CHANGE, &point);
  DispatchWindowEvent(&event);

This NS_CONTROL_CHANGE event makes it's way to the
nsFormControlFrame::HandleEvent() (forms/src/nsFormControlFrame.cpp line 610)

      case NS_CONTROL_CHANGE:
        ControlChanged(&aPresContext);
        break;
    }

nsSelectControlFrame::ControlChanged() (nsSelectControlFrame.cpp line 1034)
This then determines if the selection actually was changed.  If so, it fires off
a DOM NS_FORM_CHANGE event (line 1104):

    if (changed) {
      nsEventStatus status = nsEventStatus_eIgnore;
      nsEvent event;
      event.eventStructType = NS_EVENT;

      event.message = NS_FORM_CHANGE;
      if (nsnull != mContent) {
        mContent->HandleDOMEvent(*aPresContext, &event, nsnull, NS_EVENT_FLAG_I$
      }
    }

For your case, the GFX text widgets should also fire a DOM event after a text
change.  This event should occur when the text field looses focus (i.e., when
the user clicks outside of the text box.  There seem to be two ways of doing
this, depending on which would be easiest:

1) Fire a NS_CONTROL_CHANGE event and pass that on to the nsTextControlFrame.
2) Fire a DOM NS_FORM_CHANGE event directly.

Other events that textareas/inputs in particular may need to fire (if they are
not already) include onfocus, onblur, and onselect.  These are listed in the
HTML 4.0 spec: http://www.w3.org/TR/REC-html40/interact/forms.html#edef-TEXTAREA
*** Bug 4080 has been marked as a duplicate of this bug. ***
Depends on: 7001
For input type="text" (and probably for textarea) widgets, the onchange
needs to be when the text is changed, not just when the control looses focus.
A major use of this handler is to detect when the control has content, so
we can enable/disable associated buttons. Another use is for filtering the
text typed to suppress certain characters.
Unfortunately, this is contrary to the spec, and is also not the way that
Navigator and IE 5.0 behave.  If you want to trap each key event, you'll need to
register for the onkeydown, onkeyup, or onkeypress event.

Also, unfortunately, this event is not yet wired up.  :S
From the HTML 4
spec(http://www.w3.org/TR/REC-html40/interact/scripts.html#events)

onchange = script [CT]
The onchange event occurs when a control loses the input focus and its value has
been modified since gaining focus.
This attribute applies to the following elements: INPUT, SELECT, and TEXTAREA.
----------------------
Charlie, I think you want to sit on onkeypress events as Eric indicated.
*** Bug 10154 has been marked as a duplicate of this bug. ***
Added myself to cc list, was waiting on 10154 which has been marked as a

duplicate of this bug.  Need this fix for mailnews and addressbook, autocomplete,

entering address book data, dialogs that enable and disable buttons based on

html:input data entered in fields, etc.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
fixed
Status: RESOLVED → REOPENED
I just tested with code pulled at 4pm 8-4-99, and the onchange="" does not get
fired for html:input widgets in my xul file.
Paul--I'm pretty sure that buster's fix won't fix the problem with native platform widgets.  Is that how you are verifying?  If so, you should turn on the xp widget pref and try again.  Btw, for text widgets I'm leaning toward use of onkeypress or onkeydown so I can handle the change right away rather than after the user starts to leave the field.ã
Resolution: FIXED → ---
I am using apprunner on a Mac.  I originally filed bug 10154 which was marked as

a duplicate of this bug.  So for my part this bug is not fixed unless it works in

the New Card Dialog of the Address Book from Apprunner.
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Summary: onchange function never gets called → onchange function never gets called for GFX text control
changed the summary to reflect that the fix is for GFX text control only.
Native text widgets are no longer being supported.  Text controls will be turned
on by default early in M10.  For now, you have to manually set the pref
"nglayout.widget.mode" to 2.
Paul, if you saw this problem with GFX text controls, please reopen again.
Whiteboard: [19990909] requesting info from hangas regarding addressbook issues
hangas, does buster's fix satisfy your issues with addressbook?
Status: RESOLVED → VERIFIED
marking verified per hangas
(thanks Paul)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: